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: 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




reply via email to

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