Re: Shared library runpath trouble in Solaris.

[Alexandre Oliva <oliva@dcc.unicamp.br>]

Ian Lance Taylor writes:

> Note that if we always use a -R /usr/lib option, it will break certain
> uses of LD_LIBRARY_PATH.

Now this is a very good reason for not adding -R arguments.

So, it seems to me that the only remaining alternative is to hardcode
the full pathname of the library in the library itself.  So, if one
does not use a shared libstdc++, this is not an issue.  If one uses,
the library will know how to find itself.  I know this makes it
impossible to move the library to another directory, but there's no
such thing as a free lunch, after all.

Unfortunately, AFAIK, hardcoding library paths is not that portable,
and libtool has a lot of work trying to make this all transparent to
users.  Maybe we should borrow some shared-library knowledge from
libtool...

> What's wrong with the solution I described?
> (To repeat: do the library searching in collect2, add a -R option if a
> shared library will be used; I'm happy to make this a special case for
> libstdc++, but I think it would also be reasonable to act otherwise).

There's a problem when you're linking a program linked against a
shared library that was not installed yet.  If gcc automatically
hardcodes the library path where the library is sitting, it won't be
able to find it at run-time.

IMO, gcc should only take care of libstdc++ by itself if linking is
performed with g++ and -nostdlib is not issued.  Otherwise, let the
user take care of that by himself.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil