RE: Problem with LT_PATH_NM

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

> (But it just papers over the real bug IMHO)

I have to agree on that. 

> Cheers,
> Peter

//Peter