Re: Dynamic linker is unable to find GCC libraries

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul  5, 2000, Benoit Hudson <bhudson@ptolemy.arc.nasa.gov> wrote:

> On Wed, Jul 05, 2000 at 07:08:16PM -0300, Alexandre Oliva wrote:
>> On Jul  5, 2000, Benoit Hudson <bhudson@ptolemy.arc.nasa.gov> wrote:

>> That's not true.  Why do you think so?

> Because of
>> echo "int main() { return 0; }" > foo.cc
>> g++ foo.cc
>> ./a.out
>         ld.so.1: ./a.out: fatal: libstdc++.so.2.10.0: open failed: No such
>         file or directory

I think this depends on which operating system or linker you're using.
I think I've seen linkers discard unused libraries in the past.  But
of course I may be wrong.

> Using gcc 2.8.1 on the Solaris 2.6 box, I can't link foo.cc; but if I set
> LD_LIBRARY_PATH, link, unset, and run, it works.  ldd doesn't show a.out
> depending on libstdc++.

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.

>> add the directory containing libstdc++ to /etc/ld.so.conf
>> set the environment variable LD_RUN_PATH

> Except both these mean it'll be added to non-c++ programs too,
> right?

Yup.

> 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?

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.

But this may change when libgcc becomes a shared library.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me