Re: libtool-2.0 release [WAS per-deplib static/dynamic flags]

[Bob Friesenhahn]

On Thu, 2 Feb 2006, Bob Friesenhahn wrote:
> I have also noticed some disturbing "leakage" of default compiler (GCC) path 
> information into the build which causes -m64 to not work properly (at least 
> under Solaris, but seems likely to impact other targets as well).  This bug 
> did not used to exist on the 2.0 branch. In my test case, the compiler is 
> always run via a shell script wrapper (gcc-64) which always runs gcc with 
> -m64 so I am not sure what libtool did to encourage gcc to undo the effect of 
> that option.

In order to clarify this issue some more, the problem only happens 
when linking a C++ library and occurs because while libtool does link 
using the C++ compiler, it supplies the options '-shared -nostdlib' 
and then proceeds to tell the compiler what it should already have 
done by default except that it gets something wrong and passes the 
path to the 32-bit version of libstdc++.so rather than the 64-bit 
version the compiler would have used when given the -m64 option.  So I 
think that it is wrong for libtool to be specifying -nostdlib 
and that it would be more reliable to allow the compiler to find its 
own crt objects and libraries.  The operation may be a vestige of when 
C++ libraries were linked directly using ld, except that this problem 
did not occur a year ago so it has somehow been added since then.

Bob
======================================
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/