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

["Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>]

The following reply was made to PR c++/10268; it has been noted by GNATS.

From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de>
To: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Cc: ehrhardt@mathematik.uni-ulm.de, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
  nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/10268: C++ executables fail: libstdc++.so.5 not found
Date: Mon, 31 Mar 2003 16:44:45 +0200

 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@mathematik.uni-ulm.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!