Re: Problematic linking between glibc and shared libgcc

[Russ Allbery <rra at stanford dot edu>]

Mark Mitchell <mark@codesourcery.com> writes:

>>>>>> "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.

Oh, excellent.  Okay, I've been worrying about at least a few things that
I didn't need to worry about, then.  (This thread has been extremely
confusing.)

> 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).

This is reasonable.

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

This is excellent.

> 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.

Okay.  So what I'll immediately do is hack either gcc or our software
build process to add the directory libgcc is located in to the rpath (no
LD_LIBRARY_PATH, ick) for that particular case.  Hm.  Why can't gcc do
that by default in the case that it links with a shared libgcc?

> 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.

Right, makes sense.

> 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?

Installing libgcc_s.so in /lib, /usr/lib, or /usr/local/lib isn't
feasible, no.  But I think it's perfectly reasonable to add the path to
libgcc_s.so to the rpath when linking with it, particularly since it's
normally in a non-standard directory.  I think I can hack around that
locally if for some reason gcc can't do it itself.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>