Re: gnulib breakage on Tru64 UNIX with commercial C compiler

[Paul Eggert]

One dumb question:

Does the Tru64 compiler define __GNUC__, or some other similar symbol?

Also, Eric Blake <address@hidden> 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.