Re: LT_PATH_NM uses too strict a check

[Peter Rosin]

(for some reason, I'm not receiving all your posts...)

Den 2010-12-26 14:42 skrev Ximin Luo:
> On 26/12/10 01:00, JonY wrote:
>> No, cross compile is very normal, its expected to work fine by just
>> setting the triplets, that is what autotools is great for. You are cross
>> compiling as long as host != build. Setting --host without setting
>> --build is assumed to be cross compile.
>>
>> What GMP is doing is not normal, the way it uses those triplets. IMHO
>> they should really be using --with-arch or some such to set the CPU insn
>> levels.
>>
>> I suppose you want to set both --build and --host to be equal to each
>> other when doing GMP.
>>
> 
> I think you are completely misunderstanding the point of my bug report. The 
> bug
> is not in GMP, it is in libtool's LT_PATH_NM macro. I only mentioned GMP to
> give some background on my thought process.
> 
> The full snippet (libtool.m4) is:
> 
>   if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
>     lt_nm_to_check="$lt_nm_to_check nm"
>   fi
> 
> This means libtool will only use standard `nm` when $build == $host. It will
> overlook `nm` for (build, host) pairs of e.g.

This is not true, since it is not the "full snippet". Further down in the
macro you have this:

test -z "$NM" && NM=nm

which will trigger if no appropriate name lister is found.

> - (i686-pc-linux-gnu, i486-pc-linux-gnu)
> - (core2-pc-linux-gnu, athlon64-pc-linux-gnu)
> 
> This is too strict and unnecessary, because (AFAIK; I may be wrong) they still
> use the same object file format, and the same `nm` will work on both 
> platforms.
> 
> Again, you shouldn't have to use a completely different toolset for
> cross-compiling to a different CPU variant. libtool already mostly supports
> this; (in my case) it's just screwing up on detecting a good `nm`.

How can you be sure about that? There might be some obscure cpu-variant on some
obscure OS that implies a different object file format. Maybe not now, but maybe
in the future, who knows? I don't think it is normal to draw these kinds of
conclusions by examining subsets of the host/build triplets.

> Again, what is wrong with my suggestion (either getting rid of the test $build
> = $host, or changing it so it ignores the CPU part of the triplet?)

As suggested previously on bug-automake, I do not think you will have any
problems if you would just update to libtool 2.2.8, which is the first version
where the "link problem" has been fixed (or preferably libtool 2.4 of course).
For libtool 2.2.8 and later, libtool will go with the system nm if it fails
to find an appropriately named cross-nm. Have you even tried libtool 2.2.10,
which you claim to have this problem? Or did you simply search the code for a
couple of lines you thought to be somehow problematic?

So, I claim that you will not have this problem with current libtool. I.e., I
don't think there's any bug to see.

Cheers,
Peter