[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LT_PATH_NM uses too strict a check

From: Ximin Luo
Subject: Re: LT_PATH_NM uses too strict a check
Date: Sun, 26 Dec 2010 13:42:54 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101030 Icedove/3.0.10

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"

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.

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]