[Bug preprocessor/31186] -I/usr/include not taken into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186 --- Comment #6 from Vincent Lefèvre --- OK, so I think there is a bug in the autotools, which use -I instead of -isystem (unless this has changed).
[Bug preprocessor/31186] -I/usr/include not taken into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- 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
--- 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|-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
--- 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
[Bug preprocessor/31186] -I/usr/include not taken into account
--- 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
--- 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
