This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Problematic linking between glibc and shared libgcc
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/>