bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: header file order issue on tar-1.19/lib/inttypes.h


From: John E. Malmberg
Subject: Re: header file order issue on tar-1.19/lib/inttypes.h
Date: Thu, 20 Dec 2007 00:43:44 -0600
User-agent: Thunderbird 2.0.0.9 (Windows/20071031)

Paul Eggert wrote:
"John E. Malmberg" <address@hidden> writes:

The quick patch that I can do is to move where the #undef of the
_GL_JUST_INCLUDE_SYSTEM_DIRECTORY_H is.

Yes, thanks, that sounds like a reasonable fix.  I installed the patch
below: does it work for you?

It will take me a little bit to try it.

I still have to manually edit the .h files produced by the makefile.

It looks to me that the configure script is trying to find the path to the system include directories and then have the makefile put them in the .h files that it creates.

The configure script can not find the path on VMS because the system header files are in a text library.

What the VMS compiler does for <zzzzz/file.h> is first search for zzzzz/file.h in the -I paths, and if it is not found, then searches for the header file in the compiler specific text libraries.

So what the configure needs the makefile to insert is a non-existant path like <vms_no_path/file.h>.

Once I find a solution to that, I will be able to get rid of the manual edits to the .h files and be able to work with editing the .in files.

There are a few other changes for VMS that I have found since my initial post, but I was waiting for this issue to be responded to. Also, I have not yet completed the port to VMS. Currently I have the make phase compiling and linking, but have not tried a make check yet.

Do you want me to submit the patches as I find they are needed, or wait until I get the final program tested?

From code inspection, I need to replace the routines that call fork() and pipe() with VMS specific ones similar to what I am using in the port of Bash to VMS that finally allows VMS to run most configure and make files.

The long term fix to avoid this would be to not use the same names for
the replacement header files as the system header files,

That would mean we'd have to rewrite all our source code that includes
<stdint.h>.  We'd rather not do that.  If this becomes a real problem
on a lot of platforms I suppose we'll have to rethink things, but for
now the current approach seems to be working OK.

With the header files controlled by X/Open, you can predict what other headers they will call, but I do not know if there is any standard for the other system header files. That could change with any patch or release of the OS. But if you put guards around all of them, it should work.

It looks like you are trying to do something similar to what I have to do to work around issues with the C runtime library supplied with VMS. The VMS C Compiler has the ability to have the user specify a file to be included before the module being compiled, and I use that to put most VMS specific fixes/hacks to avoid most modifications to the source.

Since VMS puts guards in the header files to prevent them from being double included, I can do the include there with macros to modify their behavior.

-John
address@hidden
Personal Opinion Only




reply via email to

[Prev in Thread] Current Thread [Next in Thread]