On Mon, May 02, 2005 at 10:31:57AM +0200, Ralf Wildenhues wrote: > I have a question regarding systems with more than one ABI, specifically > x86_64. If you consider for example the Debian distribution which has a > x86_64 kernel, but a completely x86 userland, config.guess still gives > you x86_64-unknown-linux-gnu as output. (I have been told this, but not > tried it myself). > > Now, if you configure a package and forget to add > --build=i686-pc-linux-gnu > or maybe use the setarch tool to set personality (I do not even know how > portable/available this is -- it exists in RedHat Fedora), it may break, > e.g. because of the __x86_64__ preprocessor define. The compiler generates x86 binaries but defines __x86_64__? Weird. > Would it not make more sense to have config.guess return i686 instead of > x86_64? Is it just too late to make that change now? Maybe. If the sole purpose of host triplets was to characterize the binary $CC produces, then that would be highly appropriate. They serve other purposes as well, though. With this change, a binutils built natively on this system will be i686; as config.guess stands, it will be x86_64. Is that change okay? IMO, a tool that makes `uname' returns `i686' is more appropriate. It sounds like `setarch' may do that. SLES 9 for ppc64 includes a `powerpc32' tool that runs a program with ppc32 personality; `powerpc32 uname -m' prints `ppc'. If Debian wants to keep userspace in the dark about the true nature of its kernel, it could run the entire userspace with 32-bit personality. > How would it even be possible to detect a completely 32bit userland? You could test the compiler with `sizeof(char *)'. To ensure that a 64-bit C library is also available, link a program that uses a library function. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
