Problems with -shared and -lgcc

Problems with -shared and -lgcc

[H.J. Lu]

Hi,

I finally figured out the problems with -shared and -lgcc under
glibc. When building shared library, "gcc -shared" includes
-lgcc. It introduces a problem with glibc 2. Glibc 2 includes
many libraries. libm is one of them. When building libm.so,
libgcc.a is included by "gcc -shared", which causes many
functions in libgcc.a are included and exported in libm.so
under glibc 2.0. When libm.so is used to create an executable,
linker will use the libgcc functions in libm.so instead of
libgcc.a. In glibc 2.1, we have ELF symbol versioning. Those
libgcc functions are no longer exported in libm.so. As the
result, the executable linked with libm.so in glibc 2.0 won't
run with libm.so in glibc 2.1 since the dynamic lineker cannot
find those libgcc functions.

The problem is we do want those libgcc functions in every
executable as well as shared object. But we do not want to
export them in shared object. What we can do is use ELF
symbol versioning when it is available, that is "gcc -shared"
will pass

--version-script=/usr/lib/gcc-lib/i586-pc-linux/egcs-2.91.60/libgcc.map

to ld where libgcc.map will make all libgcc symbols global
under the old version and local under the new version.
That means the existing binaries will run fine and the
future binaries will get local copies of those libgcc
functions. Of course, it may only work with the current
GNU linker. But it is glibc 2 is now facing the problem.

I can provide a patch for egcs if it is what we want to
do.

Thanks.



-- 
H.J. Lu (hjl@gnu.org)