bug-libtool
[Top][All Lists]
Advanced

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

Re: AC_PROG_NM when compiling for mingw


From: Bruno Haible
Subject: Re: AC_PROG_NM when compiling for mingw
Date: Sat, 25 Apr 2009 02:11:25 +0200
User-agent: KMail/1.9.9

Peter Rosin skrev:
> >>> +  if test -n "$ac_tool_prefix" \
> >>> +     && { test "$build" = "$host" \
> >>> +          || { test "$build_os" = cygwin && test "$host_os" = mingw32; 
> >>> }; \
> >>> +        }; then
> >>>      lt_nm_to_check="$lt_nm_to_check nm"
> >> ...
> >> That will be wrong when Cygwin 1.7/gcc4 is released with proper
> >> cross tools for building mingw binaries, which should be
> >> Real Soon Now<tm>.
> > 
> > Can you please explain what will be wrong about it? ...
> 
> There will be one cygwin nm for dealing with cygwin binaries and one
> for dealing with mingw binaries. They will be named as they are named
> on all other systems, i.e. nm for the native one and i686-pc-mingw32-nm
> for the cross tool. ... When -mno-cygwin
> is gone you should definitely use i686-pc-mingw32-nm when dealing with
> mingw binaries.

This is good news. With the future Cygwin 1.7, when --host=i686-pc-mingw32
is given, libtool.m4 will thus set NM="i686-pc-mingw32-nm" - with or
without my proposed patch. (It adds 'nm' to the _end_ of the list
lt_nm_to_check which already contains the value i686-pc-mingw32-nm.)

So, with Cygwin 1.7, my proposed patch will be unnecessary (not wrong!).
And for Cygwin 1.5.x, it provides a clear improvement.

Cygwin 1.7 is in "Real Soon Now" mode for a couple of months already.
And when it is released, there will still be Cygwin 1.5.x users for
1-2 years at least.

Therefore, Ralf, can you please apply my patch (even if it becomes
redundant in 2 years from now)?

Bruno




reply via email to

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