RE: Problem with LT_PATH_NM

[Peter Kjellerstedt]

Seems fine to me.

//Peter

> -----Original Message-----
> From: Peter Rosin [mailto:address@hidden
> Sent: den 15 januari 2009 21:28
> To: Libtool Patches List
> Cc: Peter Kjellerstedt; Rudolf Leitgeb
> Subject: Re: Problem with LT_PATH_NM
> 
> [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