On Mon, Feb 23, 2015 at 6:00 AM, Jan Engelhardt <jeng...@inai.de> wrote: > On Monday 2015-02-23 14:29, H.J. Lu wrote: > >>On Sun, Aug 19, 2012 at 2:47 AM, Ben Elliston <b...@air.net.au> 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. _______________________________________________ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
