Re: libstdc++.so.3 not found

[Phil Edwards <pedwards at disaster dot jaj dot com>]

On Thu, Jun 21, 2001 at 01:35:37PM -0400, Al Stevens wrote:
> 1. Downloaded and installed gcc 3.0. Used the --prefix option to install it 
> in /usr/local/gcc30.

Okay.

> 2. This is a Red Hat 7.1 distribution, which means that gcc 2.96 (ugh!) is 
> installed in /usr. kgcc (egcs-2.91.66) is also installed somewhere.

Okay.

> 3. Installation went without problems. (I ran it as root, although I don't 
> know if that is necessary. The installation procedures do not specify. After 
> make install I logged in as a regular user.)

You need sufficient privs to copy files to wherever you specified as
--prefix.  If that's only writable by root, you need root privs; if that's
only writable by bob, you need either root or bob rpivs, etc.

> 4. gcc --version revealed that 2.96 is still the default.
> 
> 5. Put /usr/local/gcc30/bin at the front of PATH. Shouldn't install take care 
> of that?

How could it possibly change your PATH?  Should the install script rewrite
your .login files?  Everybody's .login files?  Everybody's .profile files?
System files?  Which system files?  Where are they?  What if you don't want
the newly-installed compiler to become the default for you/everybody?
What if you don't have appropriate permissions; should the install
fail? complain? adjust?

> 6. Compiled simple hello world C++ program.
> 
> gcc -o tester tester.cpp -lstdc++

This works.  "g++" will do the same thing, and pull in the libraries
automatically.

> 7. Got error message saying libgcc_s.so.1 could not be found. I'm wondering 
> why it needs a shared object library. I thought my command specified a static 
> link to libstdc++.a. Oh, well.

If shared libraries are available, they are used unless otherwise requested
with -static.  See the manual for more.

> 8. LD_LIBRARY_PATH=/usr/lib. Shouldn't install have fixed this? Can anyone 
> tell me what script or conf file initially sets this environment variable? I 
> haven't found it yet.

See answer #5.

> (I also tried an alternative approach: putting the path in /etc/ld.co.conf 
> and running ldconfig without changing the environment variable. That works, 
> too.)

Great.  That approach works for Linux, but only for Linux.

You can also use rpath to build the prefix/lib path into the executable
itself.  There has been debate about making this happen automatically
(there are pros and cons).  Also, you can set the LD_RUN_PATH to that
directory, and the linker will do the building-into-executable part for you.

> I suspect your installation procedures assume we know more than we do. 

The installation procedures can't assume much of anything.  In particular,
they can't assume that they know how to answer any of the questions I
posed in answer #5.

> I recompiled the program with -v to see what's happening. The linker 
> (collect2) is getting a shared library from /lib and what looks like startup 
> code from /usr/lib, which worries me:. From the linker command:
> 
> /lib/ld-linux.so.2
> /usr/lib/crt1.o
> /usr/lib/crti.o 

You should take a course in linker/loader basics, although I am at a
loss to suggest where you learn these things other than by experience.
These aren't libraries.  The first is related to the run-time loader.
Do not mess with that if you don't know what you're doing.  The crt*.o
files are hooks which make your program run (ever wondered what called
main()? now you know).  Don't mess with those either.  You may see some
other files like crt0.o on some systems; it's all startup and shutdown
code running outside your program.


Luck++;
Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.