This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: c++/10268: C++ executables fail: libstdc++.so.5 not found


This whole issue has been discussed many times on the gcc lists and
this is not going to change any time soon. Note that this doesn't
mean that I like the result of this discussion.

This is even covered by the gcc FAQ at http://gcc.gnu.org/faq.html#rpath

On Mon, Mar 31, 2003 at 12:14:10PM +0200, Hallvard B Furuseth wrote:
> ehrhardt at mathematik dot uni-ulm dot de writes:
> >     This behaviour is intentional. -R adds paths to the executable and
> >     gcc should not add system specific paths to an executable.
> >     You can either set LD_RUN_PATH at compile time or LD_LIBRARY_PATH
> >     at run time.
> 
> *What*?  Why is it better to have an executable which doesn't work than
> one where GCC has added a path which is needed to make it work?  In
> particular since the user must add the same path to make it work anyway.

Because that path might have unexpected effects if the executable is
transfered to another machine.

> If you don't want to add to the executable's path, I think you should
> only build static libraries.  If one configures gcc to build dynamic
> libraries, add the path and warn about whatever the problem is with
> adding such a path, or don't add it and give a very loud warning that
> g++ will build executables that don't work.

There is a loud warning when you install the shared libraries!

> And document this, and how one is supposed to make it work.

See the FAQ entry mentioned above.

   regards  Christian

-- 
THAT'S ALL FOLKS!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]