[Bug preprocessor/31186] -I/usr/include not taken into account

[Bug preprocessor/31186] -I/usr/include not taken into account

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The remaining environment variables apply only when preprocessing the
particular language indicated. Each specifies a list of directories to be
searched as if specified with -isystem, but after any paths given with -isystem
options on the command line.

If a standard system include directory, or a directory specified with -isystem,
is also specified with -I, the -I option is ignored. The directory is still
searched but as a system directory at its normal position in the system include
chain. This is to ensure that GCC’s procedure to fix buggy system headers and
the ordering for the #include_next directive are not inadvertently changed. If
you really need to change the search order for system directories, use the
-nostdinc and/or -isystem options. See System Headers.


This part specifically:
 If you really need to change the search order for system directories, use the
-nostdinc and/or -isystem options.

[Bug preprocessor/31186] -I/usr/include not taken into account

[vincent-gcc at vinc17 dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186

--- Comment #6 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
OK, so I think there is a bug in the autotools, which use -I instead of
-isystem (unless this has changed).

[Bug preprocessor/31186] New: -I/usr/include not taken into account

[vincent at vinc17 dot org]

When C_INCLUDE_PATH is defined and -I/usr/include is used, /usr/include should
have the precedence, but examples show that it is not taken into account.

vin:~> cat test.c
#include <mpfr.h>
vin:~> C_INCLUDE_PATH=/home/vlefevre/include gcc -E -I/usr/include test.c |
grep mpfr.h
# 1 "/home/vlefevre/include/mpfr.h" 1 3
[...]
vin:~> gcc -E -I/usr/include test.c | grep mpfr.h
# 1 "/usr/include/mpfr.h" 1 3 4
[...]
vin:~> C_INCLUDE_PATH=/home/vlefevre/include gcc -E
-I/usr/milip-local/stow/mpfr-2.2.0/mpfr/include test.c | grep mpfr.h
# 1 "/usr/milip-local/stow/mpfr-2.2.0/mpfr/include/mpfr.h" 1
[...]

The gcc man page says:

       -isystem dir
           Search dir for header files, after all directories specified
           by -I but before the standard system directories.  Mark it
           as a system directory, so that it gets the same special
           treatment as is applied to the standard system directories.

so that in the first case, the search path should be:

  /usr/include /home/vlefevre/include /usr/include

equivalent to:

  /usr/include /home/vlefevre/include

Note: this introduces an inconsistency when both -I/usr/include and -L/usr/lib
are used, since the header file is taken from C_INCLUDE_PATH and the library
file is taken from /usr/lib.


-- 
           Summary: -I/usr/include not taken into account
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vincent at vinc17 dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186

[Bug preprocessor/31186] -I/usr/include not taken into account

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-03-15 15:48 -------
I don't think this is a bug, you need to read the other part of the document
which says if you supply -I DEFAULT_DIR, it is ignored.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186

[Bug preprocessor/31186] -I/usr/include not taken into account

[vincent at vinc17 dot org]

------- Comment #2 from vincent at vinc17 dot org  2007-03-15 16:51 -------
(In reply to comment #1)
> I don't think this is a bug, you need to read the other part of the document
> which says if you supply -I DEFAULT_DIR, it is ignored.

OK, but this isn't very clear, as the description under -isystem says "*all*
directories specified by -I". I'd replace "all" by "non-ignored". The behavior
w.r.t symbolic links to such directories should also be specified.

Now, this behavior, if it is intentional, leads to 2 questions:

1. Shouldn't -L have a similar behavior to ensure consistency between library
search paths and include search paths?

2. Software is often compiled with configure, make, make install. How can one
force the compiler to look in /usr/include & /usr/lib first (i.e. override the
user's environment)?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186

[Bug preprocessor/31186] -I/usr/include not taken into account

[tromey at gcc dot gnu dot org]

------- Comment #3 from tromey at gcc dot gnu dot org  2007-05-22 19:11 -------
My recollection is that the special -I behavior is there because
the system headers have special non-warning properties.
This situation doesn't apply to -L.

> 2. Software is often compiled with configure, make, make install. How can one
> force the compiler to look in /usr/include & /usr/lib first (i.e. override the
> user's environment)?

Generally speaking this is not a good idea.  Usually people *want* their
environment to influence configure, and usually if configure overrides this
it means difficult to fix problems on weirder systems.

I am leaving this open considering that there is still a documentation bug
to be fixed here.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-05-22 19:11:27
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186

[Bug preprocessor/31186] -I/usr/include not taken into account

[vincent at vinc17 dot org]

------- Comment #4 from vincent at vinc17 dot org  2007-05-22 22:50 -------
(In reply to comment #3)
> My recollection is that the special -I behavior is there because
> the system headers have special non-warning properties.
> This situation doesn't apply to -L.

But this introduces an inconsistency, with the effect that the version of the
header and the version of the library do not match.

> Generally speaking this is not a good idea.  Usually people *want* their
> environment to influence configure, and usually if configure overrides this
> it means difficult to fix problems on weirder systems.

But configure does override the user's environment for non-system directories
(and even system directories concerning -L). That's not logical.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186