[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PATCH: Add x32 support to config.guess
From: |
Jan Engelhardt |
Subject: |
Re: PATCH: Add x32 support to config.guess |
Date: |
Mon, 23 Feb 2015 15:00:46 +0100 (CET) |
User-agent: |
Alpine 2.11 (LSU 23 2013-08-11) |
On Monday 2015-02-23 14:29, H.J. Lu wrote:
>On Sun, Aug 19, 2012 at 2:47 AM, Ben Elliston <address@hidden> wrote:
>>> There are 12 existing set_cc_for_build usages in config.guess. I
>>> don't think it is reasonable to require x32 not to use it without
>>> providing an alternative. If you want to remove set_cc_for_build,
>>> one extra usage doesn't make it much harder to do.
>>
>> That's what the person asking for the 12th instance said ..
>>
>> I don't think it's reasonable for config.guess to depend on a C
>> compiler. You would not believe how many problem reports I get due to
>> this.
>
>I realized that config.guess is more broken than I thought. Depending
>on "uname -m"[,] doesn't work with 64-bit kernel and 32-bit user space:
>
>bash-4.3# uname -m
>x86_64
>bash-4.3# gcc -v
>Using built-in specs.
>COLLECT_GCC=gcc
>COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-redhat-linux/4.9.2/lto-wrapper
>Target: i686-redhat-linux
>bash-4.3# ./config.guess
>x86_64-unknown-linux-gnu
>bash-4.3#
>
>I am expecting i686-unknown-linux-gnu, not x86_64-unknown-linux-gnu.
Well, let me chime in. There seems to be a systemic issue.
Why are we still *guessing* platform tuples, when, at least for
distributions, we could just put the *known* tuple they were built
with/for, into a file on the system, which build tools like autoconf
then can use, in the absence of command-line options like --build=, as a
default?
If we consider the above, then letting config.guess default to
uname seems like a reasonable fallback.