Re: include file problems

[Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>]

>>>>> schuller@dutiws.TWI.TUDelft.NL (Bart Schuller) writes:

|> Hello all,
|> I'm having a nasty problem with the way the MiNTlibs include hierarchy
|> works. The problem:
|> When compiling something using 'gcc -I. foo.c', strange things happen
|> when foo.c includes a file "wait.h" or "compiler.h" . Why? because
|> "wait.h" usually will include <sys/wait.h>, which in turn does a
|> #include <wait.h> . At this point the error occurs, because the -I.
|> option makes gcc include ./wait.h, not /usr/include/wait.h .

This can be fixed by changing 

#include <wait.h>

to 

#ifdef __GNUC__
#include "../wait.h"
#else
#include <wait.h>
#endif

in <sys/wait.h> (and also in the files in sys/). At least, it works
with gcc, because it always searched first relative to the directory
the include file was found.  This probably also works with other
compilers, in this case this should be adjusted.

|> I think this problem could happen on any UNIX machine when you have a
|> file ./stdio.h for example, but people don't usually do that.
|> I think having all these MiNT specific files in /usr/include is the
|> wrong thing, they should be in /usr/include/sys or /usr/include/mint.

The latter is a nice idea. The only problem is that purec doesn't grok
<mint/compiler.h>, it doesn't know about forward slashes.

----------------------------------------------------------------------
Andreas Schwab                                  "And now for something
schwab@ls5.informatik.uni-dortmund.de            completely different"