Re: LT_PATH_NM uses too strict a check

[JonY]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/26/2010 21:42, Ximin Luo wrote:
> 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.
> 

I still do not think it is an issue with libtool. You are cross
compiling, simple as that. IMHO, I think autotools should error out if
it could not find the cross compiler, so it doesn't use the host
compiler accidentally.

For your situation, you should use --build and --host to the same value
to force the use of the host compiler. Your success however is in ymmv
territory.

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

This is wrong, as Bob said, host libraries for one platform may leak all
over. Strict separation is necessary.

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

Of course you do need a different toolchain. You shouldn't be mixing
objects and libraries for i686 when you target i486. You would subtly
introduce i686 insns in the i486 libs.

> 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?)
> 

Aside from causing bloat (how would libtool know if ppc is different
from armel or alpha or i686?), what nm supports really depends on how
binutils was built, not what the host system is.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (MingW32)

iEYEARECAAYFAk0X6MMACgkQp56AKe10wHeWWQCeJi6udLylA5JOd6gWF4YLmwAH
X44AnjLrf9RCe2fivlRoJ85BRh3uHWyb
=MZgb
-----END PGP SIGNATURE-----

0xED74C077.asc
Description: application/pgp-keys