One dumb question: Does the Tru64 compiler define __GNUC__, or some other similar symbol?
Also, Eric Blake <[EMAIL PROTECTED]> writes: > If you were to change the gnulib stdio.h to use #include_next instead of > #include, would that help matters any? Maybe we need to teach the > absolute-header module to check for include_next, and use it when > supported? Although I seem to recall the concern over this was whether > preprocessors that don't understand #include_next would choke; so it would > have to be done by one of the sed expressions that creates stdio.h from > stdio_.h rather than something directly in stdio_.h. If I recall correctly, the concern wasn't over preprocessors per se, as we can easily detect at configure-time whether the preprocessor supports include_next. The concern was that some packages want to install gnulib-generated headers into shared locations where any compiler can use the headers, and therefore the headers cannot rely on features like include_next that may be supported by the installer's compiler but not by some other compiler. For the case of overriding standard headers I am thinking that this concern might be overdone. If someone installs a gnulib-generated header like "stdint.h" into a shared location they are asking for trouble, no? because so many other things can go wrong. So perhaps we should rethink this, and modify gnulib to use #include_next if available. #include_next is a lot cleaner than the current approach. Another possibility is to protect #include_next with "#if HAVE_INCLUDE_NEXT"; this might support the shared-location scenario better, albeit with some complexity added.
