This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Problematic linking between glibc and shared libgcc


>>>>> "Russ" == Russ Allbery <rra@stanford.edu> writes:

    Russ> this mechanism.  If the shared library that one is linking
    Russ> against depends on a shared libgcc, it's quite reasonable
    Russ> for the resulting binary to also depend on a shared libgcc,
    Russ> but my *ideal* world would have that be the only time that
    Russ> any C binary depends on a shared libgcc (only if it is
    Russ> linking with shared libraries with a dependency on a shared
    Russ> libgcc).

That *is* the only case when you will need a shared libgcc in C, as
the compiler is set up by default.

Here are the rules again:

  - If you create a shared library, you link against shared libgcc.

    (If you really don't need anything in libgcc, you could use
    -nodefaultlibs, I suppose).

  - If you create an executable C program, you don't link against
    shared libgcc -- unless you say -shared-libgcc.

    That's because in C having multiple libgcc's doesn't really matter
    much.  (In principle, it's just as bad in C as in any other
    language, but in actual fact, it doesn't matter.  There are
    changes we could make to libgcc that would make it matter, but we
    won't.)

So, the way you can get a shared libgcc in C is that you:

  - Create a shared library with GCC

  - Link that into a final executable.

So, the binary will need LD_LIBRARY_PATH set when it wouldn't before
only if the shared library is in /lib, /usr/lib, etc., but libgcc_s.so
is not.

Your AFS example is one way that could happen.  On the other hand, you
could just propogate libgcc_s.so to all of your machines once, and
then this problem goes away.

The reason, by the way, that creating a shared library uses libgcc_s
is that if that shared library is ever used by C++/Java/etc., then it
matters whether or not we have the static or shared libgcc.  If we
pick static by default in that case, then I believe the library will
be unusable in C++, in the general case.

Again, if we controlled the horizontal and the vertical (as many
system vendors do) then we might likely put this stuff in libc, and be
done with it.  But, we might not.  The closest approximation, on a
Solaris system, say, would be to install libgcc_s.so in /lib,
/usr/lib, or /usr/local/lib.

Is that feasible?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]