[Bug c/48910] New: Current working directory in system include search path

[Bug c/48910] New: Current working directory in system include search path

[Adam_5Wu at Hotmail dot com]

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

           Summary: Current working directory in system include search
                    path
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Adam_5Wu@Hotmail.com


Current working directory (aka. ".") is included in the system include search
path chain, which causes compilation of gcc (and other program, such as
binutils) to fail due to wrong header was matched.

The command line parameter for compiling in the gcc directory
("host-xx-xx.../gcc") have a list of include search paths, including "-I.",
"-I../libdecnumber", and others. Because "." was inserted in the system include
search path chain, its presence before the "-I../libdecnumber" was ignored by
the compiler, and its actual search order came after "../libdecnumber". There
are two different header files both named "config.h" in "libdecnumber" and
"gcc", so the compiler matches "../libdecnumber/config.h" instead of the
correct one "./config.h", which causes compilation to fail.

----
The workaround is to stop inserting "." in the system include search path
chain.

In file gcc-4.6.0/gcc/incpath.c, replace
path = xstrdup (".");
with
continue;

Note that after the change, the first stage compilation will still fail if the
host compiler has this problem. The workaround is:
1. Compile until failed
2. cd "host-xx-xx.../gcc"
3. mv ../libdecnumber/config.h ../libdecnumber/config.h-
4. Make in this directory (should complete without error)
5. mv ../libdecnumber/config.h- ../libdecnumber/config.h
6. cd ../..
7. Make again

The stage1 compiler will have this problem corrected, so the next 2 stages
should complete without error.

[Bug c/48910] Current working directory in system include search path

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-05-06 10:59:15 UTC ---
On Fri, 6 May 2011, Adam_5Wu at Hotmail dot com wrote:

> The workaround is to stop inserting "." in the system include search path
> chain.
> 
> In file gcc-4.6.0/gcc/incpath.c, replace
> path = xstrdup (".");
> with
> continue;

But that code is processing an environment variable, and it's absolutely 
standard that empty elements in PATH-like environment variables are 
processed as ".".

What environment variable is set to contain an empty element, and how did 
it get set like that?  The problem is that the environment variable is 
set, and the fix must be to stop it from being set.  If the variable was 
not set by something in GCC, then this is not a GCC bug but a problem with 
your build environment.

[Bug c/48910] Current working directory in system include search path

[Adam_5Wu at Hotmail dot com]

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

--- Comment #2 from Adam_5Wu at Hotmail dot com 2011-05-06 20:00:06 UTC ---
(In reply to comment #1)
> But that code is processing an environment variable, and it's absolutely 
> standard that empty elements in PATH-like environment variables are 
> processed as ".".
> 
> What environment variable is set to contain an empty element, and how did 
> it get set like that?  The problem is that the environment variable is 
> set, and the fix must be to stop it from being set.  If the variable was 
> not set by something in GCC, then this is not a GCC bug but a problem with 
> your build environment.

Ahh, thanks for the explanation. Yes, somehow the C_INCLUDE_PATH on my machine
contains an empty component.

This is a quite obscure problem. I have researched it for quite some time on
Google and found many people have similar problem but none had a proper
solution or explanation, which leads me to speculate it may be a bug in gcc...

For example:
http://gcc.gnu.org/ml/gcc-help/2009-11/msg00202.html
http://d.hatena.ne.jp/sugyan/20080626
http://ubuntuforums.org/showthread.php?p=7596021
http://forums.gentoo.org/viewtopic-t-797447.html
http://betterlogic.com/roger/2008/10/gcc-woe/

This one is close:
http://www.spinics.net/lists/gcchelp/msg26054.html
The author says unset "C_INCLUDE_PATH" may help but "don't know why", I was
afraid of breaking other things so I didn't proceed with that suggestion.

So it seems that having an empty component in the gcc path environment variable
probably is accidental and doesn't have desired effect most of the time.
Probably gcc should print a warning message about it (at least in verbose
mode)?

In addition, since the building of gcc relies on "." not included in any of the
paths, maybe the build script should detect it and fail early?

[Bug c/48910] Current working directory in system include search path

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-07-23 23:15:13 UTC ---
Not a GCC bug but rather a bug in the user's env.