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

[Bob Friesenhahn]

On Thu, 2 Feb 2006, Gary V. Vaughan wrote:
> According to: http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap, the
> three remaining release blockers for 2.0 are:
>
> * <!> libtool.m4 macro ordering/requirement audit. pending
> * <!> LT_WITH_LTDL should build libltdl by default; currently
>       nothing happens unless LTDL_CONVENIENCE or LTDL_INSTALLABLE
>       is also given.
> * <!> fix potential denial of service with compilers that do not
>       understand "-c -o".
>       * not very likely to happen
>       * http://lists.gnu.org/archive/html/libtool-patches/2005-03/msg00252.html

I know that Ralf is aware of a few more release-blocking issues than 
these.  One of them is to be able to libtoolize with a libltdl 
directory using the non-recursive option and end up with a subordinate 
Makefile.inc which works.  Currently the generated Makefile.inc takes 
some hand-tweaking.

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.

I have been re-libtoolizing various projects with libtool 2.0 and have 
encountered resounding success with MinGW (very good!).

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