Why does ld insist on /lib/libgcc_so.so1

Why does ld insist on /lib/libgcc_so.so1

[skelter]

I have installed GCC 3.3.2 in /usr/local/gcc-3.3.2 in order to not clobber
things in /lib and /usr/lib.  I even installed binutils, too.
Problem I'm running into now is that I can't shake dependence of
/lib/libgcc_s.so.1 .

I can compile a simple test c++ program, but it will not run, citing an
inability to locate a library, which is both old (why is it trying to find this
library?) and there (why can't it find it?).

I do not understand this.  I have searched around and found that others have run
into the same problem, but I have not found that they have found either an
explanation or a solution.  Therefore, I am committing to document whatever
explanation I find, and whatever solution I find, so that I may serve the
community that has so beautifully served me.  Please help me.  I am going quite
mad.  I will drive beer to you within a 100 mile radius of Austin, TX.  Cold
beer.

First, let us begin with the environment:  Here is g++
[ssuehs@ache openh323]$ g++ -v
Reading specs from
/usr/local/gcc-3.3.2/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Configured with: ../gcc-3.3.2/configure --prefix /usr/local/gcc-3.3.2
Thread model: posix
gcc version 3.3.2

The path:
[ssuehs@ache openh323]$ echo $PATH
/usr/local/gcc-3.3.2/bin:/usr/java/j2sdk1.4.1_02/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin

LD_LIBRARY_PATH is not set:
[ssuehs@ache openh323]$ printenv | grep LD_
[ssuehs@ache openh323]$

The program:
[ssuehs@ache openh323]$ cat > gooftest.cc
#include <stdio.h>
#include <stdlib.h>

int
main()
{

;
return 0;
}
[ssuehs@ache openh323]$ g++ gooftest.cc
[ssuehs@ache openh323]$ ./a.out
./a.out: /lib/libgcc_s.so.1: version `GCC_3.3' not found (required by
/usr/local/gcc-3.3.2/lib/libstdc++.so.5)


What does the ldd tool say about it?  Why, it confirms the problem
[ssuehs@ache openh323]$ ldd a.out
./a.out: /lib/libgcc_s.so.1: version `GCC_3.3' not found (required by
/usr/local/gcc-3.3.2/lib/libstdc++.so.5)
	libstdc++.so.5 => /usr/local/gcc-3.3.2/lib/libstdc++.so.5 (0x40034000)
	libm.so.6 => /lib/i686/libm.so.6 (0x400ef000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40112000)
	libc.so.6 => /lib/i686/libc.so.6 (0x4011a000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[ssuehs@ache openh323]$ which as
/usr/local/bin/as
[ssuehs@ache openh323]$ which ld
/usr/local/bin/ld
[ssuehs@ache openh323]$ which ldd
/usr/bin/ldd
[ssuehs@ache openh323]$ ls -lh /usr/local/bin/ld
lrwxrwxrwx    1 root     root           23 Dec  3 12:56 /usr/local/bin/ld ->
../binutils-2.14/bin/ld
[ssuehs@ache openh323]$

[ssuehs@ache openh323]$



I have added /usr/local/gcc-3.3.2/lib to /etc/ld.so.conf as follows
/usr/local/gcc-3.3.2/lib
/usr/local/binutils-2.14/lib
/usr/local/lib
/usr/kerberos/lib
/usr/X11R6/lib
/usr/lib/sane
/usr/lib/qt-1.45/lib
/usr/lib/wine
/usr/lib/mysql

I tried adding them to the bottom, too.
Each time, I did run ldconfig as root


At work we are required to stay at RedHat 7.2 .
Some woes regarding Oracle 8.1.7, and our software and kernel versions, and more
grief.
[ssuehs@ache openh323]$ cat /etc/redhat-release
Red Hat Linux release 7.2 (Enigma)

RE: Why does ld insist on /lib/libgcc_so.so1

[lrtaylor]

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

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

Cheers,
Lyle

-----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
/usr/lib
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
my
case) says the order is
DT_RPATH,LD_LIBRARY_PATH,DT_RUNPATH,/etc/ld.so.cache,trusted /lib &
/usr/lib

I do not doubt that it works, or that you are correct.  I am trying
understand
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?

-s

RE: Why does ld insist on /lib/libgcc_so.so1

[skelter]

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 /usr/lib
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 my
case) says the order is
DT_RPATH,LD_LIBRARY_PATH,DT_RUNPATH,/etc/ld.so.cache,trusted /lib & /usr/lib

I do not doubt that it works, or that you are correct.  I am trying understand
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?

-s

RE: Why does ld insist on /lib/libgcc_so.so1

[lrtaylor]

The problem is that, while GCC automatically links to the libraries that
come with it, it doesn't embed the path to those libraries in the
executable.  So, your program will know that it depends on
libgcc_s.so.1, but it won't know where to find it.  When you run your
program, the system will look in the default library search directories
(of which /usr/lib is always one) and then find it there, instead of
where you have it installed under /usr/local.  Now, while the library
may have the same name as the one that your program was linked to, it is
an older version, and the linker knows this.  When you built your
program with GCC 3.3.2, it embedded the version of the library it needs
in the program, and when the linker saw that the version it wanted was
not what was in /usr/lib, it gave you the error that you saw.

What if you set LD_LIBRARY_PATH to the location of the correct
libgcc_s.so.1?

Cheers,
Lyle

-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of skelter@spamcop.net

I have installed GCC 3.3.2 in /usr/local/gcc-3.3.2 in order to not
clobber
things in /lib and /usr/lib.  I even installed binutils, too.
Problem I'm running into now is that I can't shake dependence of
/lib/libgcc_s.so.1 .