Seems fine to me. //Peter
> -----Original Message----- > From: Peter Rosin [mailto:p...@lysator.liu.se] > 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:p...@lysator.liu.se] > >> Sent: den 14 januari 2009 21:27 > >> To: Peter Kjellerstedt > >> Cc: bug-libt...@gnu.org > >> 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:p...@lysator.liu.se] > >> Sent: den 14 januari 2009 22:38 > >> To: Peter Kjellerstedt > >> Cc: bug-libt...@gnu.org > >> 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 <p...@lysator.liu.se> > > 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