Re: Problematic linking between glibc and shared libgcc

[Brad Lucier <lucier at math dot purdue dot edu>]

Mark wrote:

> C programs that do not use shared libraries built with GCC are
> absolutely unaffected.  That includes C programs that link with shared
> libraries provided by the system vendor.
> 
> What won't work is C++ programs built with GCC, or shared libraries
> built with GCC -- unless you use -static-libgcc.

This is very interesting.

I first noticed the shared libgcc issue when I built Gambit-C with
gcc-3.0-branch in my usual way:  The runtime library modules and
compiled and linked with

gcc -shared -o libgambc.so <objects>

to build a shared runtime library; then the applications themselves are
compiled and run with, basically,

% env LD_LIBRARY_PATH=<location of gambit's shared library> gcc -o test test.c -lgambc
% env LD_LIBRARY_PATH=<location of gambit's shared library> ./test

This bombed; after reading your e-mail I linked the gambit runtime with

gcc -shared -static-libgcc -o libgambc.so <objects>

and everything worked, just as you say!

I then tried it with gcc-2.95.1 and found out that -static-libgcc is
not a valid option for that compiler.  So people building applications
with the new version of gcc seems to have the option of doing some
configurey to see which version of gcc they're using to see how to get
this right, or tell the use that they better have the directory
containing libgcc.so in their LD_LIBRARY_PATH.

Now, I wouldn't have noticed this if

gcc -shared -o libgambc.so <objects>

wouldn't have pulled in libgcc.so at this point, but rather it would have
been delayed until

gcc -o test test.c -lgambc

at which point it would have pulled in the static version.  Is this
impossible (or undesirable) for another reason I don't understand?

Brad