Dynamic linker is unable to find GCC libraries

[Benoit Hudson]

On Thu, Jul 06, 2000 at 12:23:33AM -0300, Alexandre Oliva wrote:
> See?  It's discarding the shared library.  But collect2 needs to find
> the library, and it depends on being able to find it, that's why you
> need LD_LIBRARY_PATH.

Great!  An old version discards the library.  For some reason, a newer
version decides it can't discard (I'm using the same ld).  Why should me,
the user, care?

collect2 clearly is able to find its library without an LD_LIBRARY_PATH.
It's trivial to do: just hard-code the path into gcc when we compile gcc.
We need to do this for crt1.0 and so on anyway; why not put libstdc++ there
too?  (and in fact, it is there, for 2.95.2).


> > Even less palatable, as you point out.  I've had to fix enough old binaries
> > whose libraries went away to know that hard-coding the filename would be
> > bad.
> 
> So why do you want to use -R in the first place?

-R adds a path; if it's not found there, it'll look elsewhere in the path.
Unless I've misunderstood ld -h, with that the library is declared to be in
a specific place and nowhere else.  If I've misunderstood, then ok, that's
one solution.  Still, it's a solution you're requiring the user to know
about.


> There's no win-win solution; all of them are bad, looking from a
> certain point of view.  That's why GCC simply leaves this up to the
> user.

This then requires the user to know that, for most compilers, you just type
'CC' or whatever; but for gcc, you have to first figure out where libstdc++
is, then set LD_LIBRARY_PATH, then run 'c++'.  And if you didn't specify
the -R option, then to even just _run_ the program, you have to tell
everyone using it to set LD_LIBRARY_PATH!

There is a win-win solution: c++ should know where it installed its library
(which it now does, post-2.8.1); and should figure out whether its library
is actually used (which is always, currently, under two common platforms);
and if so, should add the -R flag.

Second-best: c++ always sets -R, even if libstdc++ is eventually discarded
by ld; allow a switch for expert users to use that turns off the automatic
-R, should they happen to know that (a) the program doesn't use libstdc++,
and (b) their compiler/os/ld combo discards libstdc++.  

Or don't provide the switch; g++ is basically 'gcc -Lgcc-lib... -lstdc++
$@' is it not?  So an expert user can run gcc directly to get what they
want.


The basic point is that gcc as a tool should not require the user of said
tool to understand implementation details of the tool.  An expert user may
find it useful to delve into the guts of gcc, but the non-unix-hacker type
(for instance, the engineers and scientists who might use my tool)
shouldn't be required to just to get things to work.  

This is the reason we all switched to autoconf, libtool, and such things:
to be able to provide a software package that works out of the box on most
machines.  Now you're asking me to tell my users that "if you use gcc, you
have to first set your LD_LIBRARY_PATH appropriately.  This is how to tell
that you're using gcc.  This is how to set LD_LIBRARY_PATH; ask your
sysadmin what to set it to."

        -- Benoit