Vincent Lefevre <vincent-opgr@vinc17.org> wrote, on 30 Jul 2009:
>
> Some time ago, I submitted the following bug report about the GCC
> behavior concerning the -I option, as this leads to non-conforming
> c99 utilities provided by some vendors (e.g. Debian).
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
>
> I got a reply (see comment #1) saying that this "sounds like it is
> mainly a defect in POSIX".
>
> Any comment?
Without getting into the details of that bug, I'm inclined to
agree with the general point that POSIX should address what
happens when a directory specified with -I is one of the places
that are searched for headers by default.
On systems where headers are plain files in system directories,
and more than one directory is searched by default, the order of
searching is likely to be important and if specifying one or more
of those directories with -I alters the order that those
directories are searched then the standard should say the behaviour
is unspecified.
The point about C99 7.1.2#3 is also valid. POSIX should extend
that rule to cover the standard POSIX headers that are not in C99.
As to the bug itself (as reported in debian bug #533124), it seems
to me that the underlying problem is not so much the issues
mentioned above, but the surprising fact that gcc on that system
searches /usr/local/include before /usr/include by default. When
I install software under /usr/local, I expect to have to use -I to
make use of header files installed there. Removing
/usr/local/include from the default search path would cure your
problem.
--
Geoff Clare <g.clare@opengroup.org>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|