This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: drow at mvista dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 20 Feb 2003 16:09:41 +0100
- Subject: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken
(Hmm, gcc-bugs or gcc-patches? Better avoid both. It's
"discussion of particular patches" with expected follow-up
discussion even more, so let's go with that.)
First of all, thanks for the sysroot stuff. However, my
non-sysrooted cross cris-axis-linux-gnu test-setup broke between
Feb 12 and Feb 16, and I suspect these changes. I use
--prefix=/home/hp/work/axis/build/gcc3testprefix and some
symlinks at that prefix pointing to another place. Not really
the normal case, but it works (worked) for testing purposes.
I spot /usr/local/include in the default search list (-v). I
think it's due to this bug:
cppdefault.h:
#if defined (CROSS_COMPILE) && !defined (TARGET_SYSTEM_ROOT)
# undef LOCAL_INCLUDE_DIR
# undef SYSTEM_INCLUDE_DIR
# undef STANDARD_INCLUDE_DIR
#else
# undef CROSS_INCLUDE_DIR
#endif
configure.in:497:
TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"$(TARGET_SYSTEM_ROOT)\"'
configure.in:521:
TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=0'
That is, TARGET_SYSTEM_ROOT is always defined, to 0 in the
unused case, so the #if defined-test always yields true. I see
no other macro that can be tested as a trivially replacement so
I leave the fix to you.
In an attempt to recover, I remove the "&& !defined
(TARGET_SYSTEM_ROOT)" above. I find that ../-expansion has
changed. Using -v, it no longer reports the equivalent of the
include-path on the 3.2 branch and 3.3 branch:
/home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris-linux/3.3/../../../../cris-linux/sys-include
Here, /home/hp/work/axis/build/gcc3testprefix/cris-linux/sys-include
is where the glibc headers are found, with cris-linux being a
symlink to the real location. Not finding system headers breaks
the build of course.
Clues? Patches? Request for better report? I may eventually
find the bug, but clues to speed up the process are welcome and
my testing suffers in the meantime.
brgds, H-P
PS. Still about a month behind on gcc mailing lists.