config-patches
[Top][All Lists]
Advanced

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



reply via email to

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