Why does ld insist on /lib/libgcc_so.so1

lrtaylor@micron.com lrtaylor@micron.com
Thu Dec 4 22:38:00 GMT 2003

Happy to _try_ and help. :-)

I don't know that you're reading the documentation wrong, and I may not
have ready your original e-mail carefully enough, either...

Are you saying that it does work if you set LD_LIBRARY_PATH?

No, didn't mean to say that /usr/lib gets searched first, it's just
always in the search path by default, from what I understand.  That is,
it will always search /usr/lib if it can't find the library somewhere
else - like you have it listed below.  I'm not sure why it didn't work,
when you put the directory in ld.so.conf, unless ldconfig just can't
handle libraries with the same name in two places like that.

With something like this, though, I'm not sure it's a good idea to put
that directory in ld.so.conf, anyway.  Most everything else on your
system is going to be have been compiled with the default compiler for
the system (GCC 2.96?).  Since C++ applications (and probably others)
are going to be incompatible with the libraries for GCC 3.3, you don't
want other applications picking those up instead of the ones in
/usr/lib.  The approach I would take if I were using a different
compiler than the system compiler would be to have shell scripts that
set LD_LIBRARY_PATH appropriately for the applications built with GCC
3.3 before running them.  Basically, you'd end up with a wrapper shell
script for applications built with GCC 3.3.  Does that make sense?

In addition, you might try embedding the path to your GCC 3.3 libraries
into any libraries or executables that you build.  Take a look at the
-rpath option for the linker (specified as -Wl,-rpath,directory to the
compiler).  When you embed the path in the binary, the linker should
look in that directory before directories listed in ld.so.conf, etc.
(Note, however, that LD_LIBRARY_PATH will get searched _before_ embedded

OK.  I just went back and reread your original e-mail more carefully.
This looks like a problem we were seeing (to which the two suggestions
above are our solution).  The problem appears to be that g++ linked your
program with libstdc++, but not directly with libgcc_s.so.1.  libstdc++
then depends on libgcc_s.  It looks like your program knows how to find
the version of libstdc++ that it needs (perhaps that path has been
embedded in the binary).  However, when it tries to load libstdc++, it
finds that it needs libgcc_s.  The problem is that libstdc++ does not
have the path to libgcc_s embedded in it, and the linker does not use
the path embedded in the program binary when looking for libraries
needed for dependent libraries.

For example, let's say that you have program A that uses library B which
in turn uses library C, and B and C are in the same directory.  You've
embedded the path to B and C in your program A.  However, B does not
have the path to C embedded in it.  When your program runs, it will know
where to find library B (due to the embedded path) and attempt to load
it.  When it does so, it will see that it needs library C.  However, it
will not use the path embedded in A to find C, since A does not directly
depend on C.  And, since there is no path embedded in B, it will use the
default search paths to try to find C.  That's going to include any
paths in LD_LIBRARY_PATH, ld.so.conf, /usr/lib, etc.  However, if the
directory containing B and C is not in that list somewhere, it's not
going to find it.

In your case, library B is libstdc++, and library C is libgcc_s.so.1,
and it works out that there is a library of the same name in /usr/lib
which is getting ld confused (which may be why it still couldn't find
the right version when the right path was included in ld.so.conf) and
which is not compatible with what libstdc++ said it needs.

Does that make sense?

In our case, we have a little wrapper application that sets up
LD_LIBRARY_PATH, etc., properly for the application being run so that it
picks up the right libraries.  Changing ld.so.conf or globally modifying
LD_LIBRARY_PATH is probably a bad idea, because you're likely to brake
other (system) applications at the same time.

I hope this helps a little....

I'm in Boise.  No beer necessary.  :-)


-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of skelter@spamcop.net
Sent: Thursday, December 04, 2003 1:45 PM
To: gcc-help@gcc.gnu.org
Subject: RE: Why does ld insist on /lib/libgcc_so.so1

Quoting lrtaylor@micron.com:
> What if you set LD_LIBRARY_PATH to the location of the correct
> libgcc_s.so.1?

Why!  Then it seems to run just fine?  You say the loader hits /lib and
first before going through the libraries described in /etc/ld.so.cache?
Am I
just reading the documentation incorrectly?  The man page of ld.so (8 in
case) says the order is
DT_RPATH,LD_LIBRARY_PATH,DT_RUNPATH,/etc/ld.so.cache,trusted /lib &

I do not doubt that it works, or that you are correct.  I am trying
why it does not work the way I thought it should

By the way, thank you for the help and what is your location and
favorite beer?


More information about the Gcc-help mailing list