Re: Problem with LT_PATH_NM

[Peter Rosin]

[Moving to the patches list]

Peter, Rudolf, are you ok with being added to the THANKS file?

(Rudolf, this is in reference to your libtool bug report last month)

Den 2009-01-15 09:57 skrev Peter Kjellerstedt:
> > -----Original Message-----
> > From: Peter Rosin [mailto:address@hidden
> > Sent: den 14 januari 2009 21:27
> > To: Peter Kjellerstedt
> > Cc: address@hidden
> > Subject: Re: Problem with LT_PATH_NM
> >
> > Den 2009-01-14 14:29, skrev Peter Kjellerstedt:
> > > The other day I downloaded and tried to build the latest
> > > version of stable glib (2.18.4) where they apparently had
> > > switched from libtool 1.5.x to libtool 2.2.x. The build
> > > failed with the following error:
> > Are you perhaps cross-compiling (host != build), in that case
> > you are probably hitting this:
> >
> > http://lists.gnu.org/archive/html/bug-libtool/2008-12/msg00019.html
> >
> > .oO(Should have remembered that post earlier...)
> >
> > Cheers,
> > Peter
>
> Ah yes, forgot to mention that we are in fact cross-compiling.
> And from my further testing, it seems the $PATH handling works 
> correctly, it is just that it never looks for "nm" since we are 
> cross-compiling. But I do not understand why that isn't done, 
> since NM is set to nm unconditionally at the end anyway if 
> nothing has been found. So IMHO it might just as well search 
> for it properly. But I guess there may be more to it...
>
> Also, from my further testing I realized why it did not pick
> up ${ac_tool_prefix}nm (incorrect argument given to --host),
> so now we have it properly fixed on our end as well. :) The
> reason this has not turned up earlier for us is that all the
> other cross-compiling tools like $(CC), $(STRIP), $(OBJDUMP)
> etc were passed explicitly to configure. The only missing one
> was of course $(NM)...
>
> > -----Original Message-----
> > From: Peter Rosin [mailto:address@hidden
> > Sent: den 14 januari 2009 22:38
> > To: Peter Kjellerstedt
> > Cc: address@hidden
> > Subject: Re: Problem with LT_PATH_NM
> >
> > Den 2009-01-14 20:24 skrev Peter Rosin:
> > > Den 2009-01-14 14:29 skrev Peter Kjellerstedt:
> > > > * the second is that my /usr/bin/link should not be used as NM
> > > >   since it obviously does not support the options required (as
> > > >   it is the wrong program).
> > > Can't argue about that, but you should never end up looking for
> > > "link" if you have nm on your path, so that's a red herring in
> > > my opinion. If the nm locator code is fixed, this is a non-issue.
> > > Further, if nm is not on $PATH, it doesn't make any sense to
> > > set NM=nm.
> > Here's a patch that makes the configure check a bit more picky
> > about what it recognizes as "dumpbin". As it happens, the MS
> > dumpbin outputs:
> >
> > Microsoft (R) COFF/PE Dumper Version x.yy.zzzzz.www
> >
> > as its first line of output, so I'm triggering on *COFF*
> >
> > With this patch, the old fallback (NM=nm) should kick in and
> > save you.
> >
> > Does this help?
>
> I have not tested the patch, but from reading it I would say that
> it would have saved us.

I have tested it on cygwin, with /usr/bin/nm renamed, no dumpbin
on $PATH and with /usr/bin/link being the first link on $PATH. This
link is the one from coreutils, which is not at all what we are
looking for. Relevant configure output:

checking for BSD- or MS-compatible name lister (nm)... no
checking for dumpbin... no
checking for link... link -dump
checking the name lister (nm) interface... BSD nm

As you can see in the last line, nm is selected as the name lister
even if it's not on $PATH, so the fallback is now what it was before
the dumpbin addition. If I then hide that link and reveal a MS
link.exe on $PATH (but no dumpbin.exe), I get this instead:

checking for BSD- or MS-compatible name lister (nm)... no
checking for dumpbin... no
checking for link... link -dump
checking the name lister (link -dump -symbols) interface... MS dumpbin

And then the common case, with a good nm on $PATH:

checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm

Overriding with NM="dumpbin -symbols" gets you this:

checking for BSD- or MS-compatible name lister (nm)... dumpbin -symbols
checking the name lister (dumpbin -symbols) interface... MS dumpbin

So, I feel confident that this works as intended.

> > (But it just papers over the real bug IMHO)
>
> I have to agree on that. 

Even though this is not fixing the "real" bug, it is the conservative
thing to do, as it closes the "regression". Ok to apply with this
ChangeLog?

2009-01-15  Peter Rosin  <address@hidden>

        Don't settle for any dumpbin/link program as name lister.
        * libltdl/m4/libtool.m4 (LT_PATH_NM): When locating dumpbin or
        link -dump, check if they appear to really be capable of name
        listing, in order to eliminate e.g. link from coreutils. This
        makes the name lister decision fall back on nm as the default if
        no acceptable candidate is found.
        * THANKS: Update
        Reports by Rudolf Leitgeb and Peter Kjellerstedt.
        
Cheers,
Peter

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index b7b566d..4968bf8 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3156,7 +3156,19 @@ if test "$lt_cv_path_NM" != "no"; then
   NM="$lt_cv_path_NM"
 else
   # Didn't find any BSD compatible name lister, look for dumpbin.
-  AC_CHECK_TOOLS(DUMPBIN, ["dumpbin -symbols" "link -dump -symbols"], :)
+  if test -n "$DUMPBIN"; then :
+    # Let the user override the test.
+  else
+    AC_CHECK_TOOLS(DUMPBIN, [dumpbin "link -dump"], :)
+    case `$DUMPBIN -symbols /dev/null 2>&1 | sed '1q'` in
+    *COFF*)
+      DUMPBIN="$DUMPBIN -symbols"
+      ;;
+    *)
+      DUMPBIN=:
+      ;;
+    esac
+  fi
   AC_SUBST([DUMPBIN])
   if test "$DUMPBIN" != ":"; then
     NM="$DUMPBIN"