From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexandre Oliva To: Ian Lance Taylor Cc: tot@trema.com, egcs@cygnus.com Subject: Re: Shared library runpath trouble in Solaris. Date: Tue, 11 Nov 1997 12:28:00 -0000 Message-id: References: <199711111710.MAA13467@subrogation.cygnus.com> X-SW-Source: 1997-11/msg00423.html 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