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: H.J. Lu
Subject: Re: PATCH: Add x32 support to config.guess
Date: Mon, 23 Feb 2015 06:32:35 -0800

On Mon, Feb 23, 2015 at 6:00 AM, Jan Engelhardt <address@hidden> wrote:
> 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?
>

This is a different issue from config.guess. When it used, config.guess
should provide the best result it can find.

-- 
H.J.



reply via email to

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