On Sat, 7 May 2005, Ralf Wildenhues wrote: > Sorry for the long response delay. And thank you everyone for providing > useful information. Sorry too, for not popping into this discussion earlier. > * Noah Misch wrote on Tue, May 03, 2005 at 03:57:07AM CEST: > > 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. > > Now that you mention it, I don't think it does. It might just be a bug > in the configuration of the package, but I'm not sure yet. I'll go and > check this. No, the compiler does not define __x86_64__. The application's config.h.in contains #ifndef __x86_64__ #undef __x86_64__ #endif and config.guess (through configure) generates #ifndef __x86_64__ #define __x86_64__ 1 #endif from that. The compiler internally defines __i386__. The presence of the two defines causes compile-time problems because certain sections in the source code try to do special things depending on which architecture is defined. One could go ahead and write #if defined(__i386__) && !defined(__x86_64__) wherever there was a #ifdef __i386__ but that looks rather silly. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/> _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
