libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool/ltmain.sh pulling in wrong stdc++


From: Ralf Corsepius
Subject: Re: libtool/ltmain.sh pulling in wrong stdc++
Date: Thu, 04 Aug 2005 05:51:03 +0200

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]