[Top][All Lists]
[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: |
Fri, 24 Apr 2009 03:53:24 +0200 |
User-agent: |
KMail/1.9.9 |
Hello Ralf,
> > Two things are wrong here:
> > 1) the non-recognition of the 'nm' program,
> > 2) the use of the wrong 'link' program. In the Cygwin environment, 'link'
> > is the POSIX 'link' command [1] from coreutils, not the Microsoft
> > Visual
> > Studio linker.
>
> I think both have been fixed in a post-2.2.6a patch, at least (2) has.
Thanks for the tip. Indeed, (2) has been fixed:
With LT_PATH_NM from the newest libtool.m4 I get:
checking for BSD- or MS-compatible name lister (nm)... no
checking for i586-pc-mingw32-dumpbin... no
checking for i586-pc-mingw32-link... no
checking for dumpbin... no
checking for link... link -dump
checking the name lister (nm) interface... BSD nm
This output is a bit confusing (because it uses AC_CHECK_TOOLS instead of
AM_PATH_PROG_WITH_TEST), but it does the right thing: It sets DUMPBIN to ':'.
Regarding part (1): I asked
> should the user explicitly pass NM="nm" as argument to 'configure'?
You said:
> You can try git Libtool or set NM as a workaround.
It appears that the user is usually not supposed to set NM when invoking
configure.
- The GNU standards don't go into details which variables the user should
pass to configure.
- "configure --help" lists the following variables only:
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS C/C++/Objective C preprocessor flags, e.g. -I<include dir>
if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
- The INSTALL file mentions only CC, CFLAGS, LIBS.
So, this means, NM is too low-level; many developers probably don't even know
what "nm" does and why this is important for libtool.
Therefore I propose to make LT_PATH_NM know about this case. With the attached
patch, I get the output:
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
2009-04-23 Bruno Haible <address@hidden>
* libltdl/m4/libtool.m4 (LT_PATH_NM): Try "nm" program also when
compiling for mingw in a cygwin environment.
--- libltdl/m4/libtool.m4.orig 2009-04-24 03:43:53.000000000 +0200
+++ libltdl/m4/libtool.m4 2009-04-24 03:25:41.000000000 +0200
@@ -3172,7 +3172,10 @@
lt_cv_path_NM="$NM"
else
lt_nm_to_check="${ac_tool_prefix}nm"
- if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
+ 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"
fi
for lt_tmp_nm in $lt_nm_to_check; do
- AC_PROG_NM when compiling for mingw, Bruno Haible, 2009/04/23
- Re: AC_PROG_NM when compiling for mingw, Ralf Wildenhues, 2009/04/23
- Re: AC_PROG_NM when compiling for mingw,
Bruno Haible <=
- Re: AC_PROG_NM when compiling for mingw, Ralf Wildenhues, 2009/04/25
- Re: AC_PROG_NM when compiling for mingw, Bruno Haible, 2009/04/25
- Re: AC_PROG_NM when compiling for mingw, Peter Rosin, 2009/04/27
- Re: AC_PROG_NM when compiling for mingw, Bruno Haible, 2009/04/27