> ----------------------------------------------------------------------
> (0000171) Don Cragun (manager) - 2009-08-05 20:00
> http://austingroupbugs.net/view.php?id=129#c171
> ----------------------------------------------------------------------
> <pre>
> The way the current standard is written, if I have the command line:
> c99 foo.c -I $HOME/include bar.c
> and foo.c contains:
> #include "foo.h"
> the foo.h header should not be found if it is in $HOME/include when
> compiling foo.c even though it would be found in bar.c. It should be
> found in both foo.c and bar.c with the command line:
> c99 -I $HOME/include foo.c bar.c
As currently written, the standard does not allow the order of -I
options with respect to pathname operands to be significant. That
part only applies to -l options:
The order of specifying the -I, -L, and -l options, and the order
of specifying -l options with respect to pathname operands is
significant.
My proposed change would not alter the requirements for -I options.
> Isn't this what is supposed to happen?
I tried it with SunStudio and gcc, and they both found foo.h in
foo.c even though the -I option came after foo.c. As per the
standard.
--
Geoff Clare <g.clare@opengroup.org>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|