Re: Problematic linking between glibc and shared libgcc

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Brad" == Brad Lucier <lucier@math.purdue.edu> writes:

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

Correct.

    Brad> Now, I wouldn't have noticed this if

    Brad> gcc -shared -o libgambc.so <objects>

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

    Brad> gcc -o test test.c -lgambc

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

As I understand it, that's not really possible, in general.  It
depends on the exact linker semantics in play.  In general, though,
you're supposed to tell the linker how to find the unresolved
externals in libgambc.so when you create it (for example, so that it
knows what versions of those symbols are required), and that means
that you have to provide the shared library at that point.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com