On Wed, 2005-08-03 at 13:46 -0500, Bob Friesenhahn wrote: > On Wed, 3 Aug 2005, Ralf Corsepius wrote: > > > On Wed, 2005-08-03 at 13:57 +0200, Graham Leggett wrote: > >> Hi all, > > > >> What method needs to be used to tell libtool to link to stdc++ that > >> belongs to the compiler being run? > > No method at all. libstdc++ is an internal library of g++ you are not > > supposed to specify explicitly. > > > > The issue you describe, indicates a miss-configured gcc or user setup. > > There is a long-standing GCC bug (ever since GCC started to use > libtool) on the Solaris platform in which the paths to the uninstalled > compiler libraries are recorded in the libstdc++.la file. That's not Solaris specific. AFAICT, it affects all platforms.
With recent GCCs, however, using make DESTDIR=<dir> install instead of make prefix=<installprefix><prefix> ... install works around this issue. > These paths > end up being used. So in order for a GCC install to be properly > usable, the compiler build directory needs to be moved or removed. > The cruft in the .la file remains. This seems to be a bug in the > modified libtool that GCC uses. ACK. > So from the get-go GCC is miss-configured under Solaris. :-( Another common trouble source is trying to install several g++'s to the same prefix in parallel. In this case, g++ (bogusly) tries to share several files (esp. its headers, runtime-libs) between these versions. A work-around is to configure gcc with --enable-version-specific-runtime-libs [I never understood why this isn't the default in GCC] Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
