Re: Should gcc add RPATH for libstdc++.so?

[cgd at sibyte dot com (Chris G. Demetriou)]

gbsadler1@lcisp.com (Gordon Sadler) writes:
> Anyone that follows Debian can give you the gist of why this is a not so
> good thing... Users can change LD_LIBRARY_PATH in their $HOME/.bashrc or
> equivalent. Admins can modify /etc/ld.so.conf. If you hardcode rpath
> into a lib or binary... You cannot effectively move it after you install
> it. Nightmares for packagers.

Of course, LD_LIBRARY_PATH has its own set of issues that can be
troublesome.

Some systems don't support an /etc/ld.so.conf that lets you modify
shared library search path, and also discourage use of LD_LIBRARY_PATH
(because of the problems that it can present).  The notion being,
basically, RPATH is the way ELF shared library lookup is supposed to
be specified in binaries, and the semantics around shared library
lookup work best when it's done using properly-specified RPATH
entries.  An example of this is NetBSD.

On those systems, you have three choices:

* set RPATH info at link time,

* use LD_LIBRARY_PATH (with its attendant problems, and
despite the fact that from a tool user's perspective that's very
broken), or

* don't use shared libs at all.

For systems like that, not only should the shared libstdc++ library
path be included, it pretty much _has_ to be included if you're going
to be using the shared library.


(This is a problem elsewhere in the tools, as well...  I'm just now
working around a problem with gdbtk/insight builds on NetBSD, where
it's not finding the X11 shlibs, because they weren't adequately
RPATH'd in...)


cgd