On 2007-04-06 I wrote:
> 2007-04-06 Bruno Haible <[EMAIL PROTECTED]>
>
> Fix problem with Compaq (ex-DEC) Desktop C compiler on Tru64.
> * lib/math_.h [__DECC]: Include the overridden include file through
> #include_next, outside the double-inclusion guard.
> * lib/stdio_
On Wed, Apr 04, 2007 at 10:45:44PM -0500, Albert Chin wrote:
> On Wed, Apr 04, 2007 at 09:14:12PM -0600, Eric Blake wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > According to Albert Chin on 4/4/2007 8:59 PM:
> > >
> > > Unfortunately, "#include_next " doesn't include
> > >
PS: Likewise for .
*** lib/inttypes_.h 21 Feb 2007 00:02:37 - 1.8
--- lib/inttypes_.h 6 Apr 2007 12:51:45 -
***
*** 21,27
which in turn includes this file. */
#if ! defined INTTYPES_H || defined _GL_JUST_INCLUDE_ABSOLUTE_INTTYPES_H
# if @HAVE_INTTYPE
Eric Blake wrote:
> > "-nodtk" has already been found to be the
> > preferred workaround against this system's broken .
>
> But that was before the introduction of the wchar and absolute-header
> modules, so perhaps in fixing absolute-header to use #include_next when
> possible we can ALSO fix thi
Albert Chin wrote:
> If I change:
> #include "///usr/include.dtk/stdio.h"
> to:
> #include_next
> then it works as expected (./stdio.h, /usr/include.dtk/stdio.h,
> /usr/include/stdio.h).
>
> If I #include_next "///usr/include.dtk/stdio.h", it does not.
Thanks for these tests.
Furthermore th
Paul Eggert asked:
> Does the Tru64 compiler define __GNUC__, or some other similar symbol?
It defines __DECC. [1] is a handy resource for this.
Both "cc" and "cc -nodtk" define __DECC to the same value, and both support
#include_next.
Bruno
[1] http://predef.sourceforge.net/
On 5 Apr 2007, at 17:43, Paul Eggert wrote:
One dumb question:
Does the Tru64 compiler define __GNUC__, or some other similar symbol?
No, it doesn't.
For the case of overriding standard headers I am thinking that this
concern might be overdone. If someone installs a gnulib-generated
heade
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 4/5/2007 5:22 AM:
> Albert Chin wrote:
>> There is a -nodtk option to the commercial C
>> compiler which reverts to the system cc but that would need to be done
>> for _most_ gnulib-using programs, something that is not des
Albert Chin wrote:
> There is a -nodtk option to the commercial C
> compiler which reverts to the system cc but that would need to be done
> for _most_ gnulib-using programs, something that is not desirable.
Why is this not desirable? "-nodtk" has already been found to be the
preferred workaround
On Wed, Apr 04, 2007 at 09:14:12PM -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Albert Chin on 4/4/2007 8:59 PM:
> >
> > Unfortunately, "#include_next " doesn't include
> > /usr/include/stdio.h. It includes "./stdio.h", the gnulib version of
> > stdi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Albert Chin on 4/4/2007 8:59 PM:
>
> Unfortunately, "#include_next " doesn't include
> /usr/include/stdio.h. It includes "./stdio.h", the gnulib version of
> stdio.h.
If you were to change the gnulib stdio.h to use #include_next instead
Tru64 UNIX ships with a C compiler. A commercial version of the
compiler is also available, with extra includes in /usr/include.dtk,
some of which add to the includes in /usr/include. The includes in
/usr/include.dtk include the files in /usr/include with #include_next.
However, because gnulib now
13 matches
Mail list logo
