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? If we consider the above, then letting config.guess default to uname seems like a reasonable fallback. _______________________________________________ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
