Brian Dessent <brian@xxxxxxxxxxx> wrote: > > Standard C header files in /usr/include such as endian.h are part of the > libc. They are not part of the compiler. So no, they are not generated > during installation of gcc, they are part of libc and installed when > libc was installed. Which is a mistake. Not gcc's mistake, but still a mistake. Headers such as limits.h, stdarg.h, setjmp.h and (in C99) fenv.h and float.h have one foot in the library and one in the compiler. You can't compile code with one set and use it with another, even on the same system and with compatible calling conventions. Endian.h is another, on any system that might support a coprocessor with different conventions. The mistake is that the C standard does not have a clean separation, despite the fact that it has a 'compiler/library' distinction (the hosted versus freestanding one). > They are just regular ordinary #defines in a header file, which by > definition means they are not built-in. ... Grrk. See the above. And take a look at FLT_ROUNDS for an apparently simple symbol that is quite horribly entangled between the preprocessor, compiler and library. > As I said already, autoconf. Well, those of us who write code that is intended to be portable to systems that we haven't heard of, and are based on principles that aren't currently used, don't use it. I posted how to do that in this case. However, I agree that using endian.h is not a good solution. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@xxxxxxxxx Tel.: +44 1223 334761 Fax: +44 1223 334679
