[Bug c/48910] New: Current working directory in system include search path
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: unassig...@gcc.gnu.org
ReportedBy: adam_...@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
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?
