[Bug preprocessor/11402] New: behavior of -I option, for default search locations, is potentially problematic

["matt_g_ at hotmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: behavior of -I option, for default search locations, is
                    potentially problematic
           Product: gcc
           Version: 3.2.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: preprocessor
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: matt_g_ at hotmail dot com
                CC: gcc-bugs at gcc dot gnu dot org

I recently got burned by the fact that specifying -I/usr/local/include seems not
to affect the actual order in which it's searched for #include'd files.

Specifically, I had two versions of the same package installed in two separate
directories: /usr/local/include/ and /usr/src/linux-2.4/include/linux/.  A
couple files were installed in both directories, but the newest versions of
those were in /usr/local/include/.  Some other files in
/usr/src/linux-2.4/include/linux/ were also needed (so just not including it in
the search path wasn't an option).  Unfortunately, there appears to be no way to
get the preprocessor to search /usr/local/include/ before another given
directory, presumably because /usr/local/include/ is one of the directories GCC
searches by default.  As a result, some files had to be copied out of
/usr/local/include/ into a temporary directory that could be searched before
/usr/src/linux-2.4/include/linux/ (even creating a symlink to
/usr/local/include/ didn't work!).

Therefore, I request that GCC's preprocessor be modified to honor the manual's
statement that directories are first searched (for #include's) in the
left-to-right order in which '-I' arguments are listed, regardless of whether
they're directories already otherwise specified to be searched.