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.z.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
