* Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken @ 2003-02-20 15:09 Hans-Peter Nilsson 2003-02-20 15:16 ` Daniel Jacobowitz 2003-02-20 19:09 ` Daniel Jacobowitz 0 siblings, 2 replies; 18+ messages in thread From: Hans-Peter Nilsson @ 2003-02-20 15:09 UTC (permalink / raw) To: drow; +Cc: gcc-patches (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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-20 15:09 Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken Hans-Peter Nilsson @ 2003-02-20 15:16 ` Daniel Jacobowitz 2003-02-20 16:24 ` Hans-Peter Nilsson 2003-02-20 19:09 ` Daniel Jacobowitz 1 sibling, 1 reply; 18+ messages in thread From: Daniel Jacobowitz @ 2003-02-20 15:16 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches On Thu, Feb 20, 2003 at 04:09:41PM +0100, Hans-Peter Nilsson wrote: > (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. Blech. I'll fix this in a couple of minutes, I want to check if I did the same thing elsewhere. > 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. Better report. Could you give me the output of gcc -v for 3.3-branch and HEAD? You said thre were "a couple of symlinks" involved - what others? For instance do you use a symlink to the gcc binary? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-20 15:16 ` Daniel Jacobowitz @ 2003-02-20 16:24 ` Hans-Peter Nilsson 2003-02-20 18:49 ` Daniel Jacobowitz 0 siblings, 1 reply; 18+ messages in thread From: Hans-Peter Nilsson @ 2003-02-20 16:24 UTC (permalink / raw) To: drow; +Cc: hans-peter.nilsson, gcc-patches > Date: Thu, 20 Feb 2003 10:16:01 -0500 > From: Daniel Jacobowitz <drow@mvista.com> > On Thu, Feb 20, 2003 at 04:09:41PM +0100, Hans-Peter Nilsson wrote: > > 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. > > Better report. Could you give me the output of gcc -v for 3.3-branch Compiling fixunsdfsi is where it fails, so I'll show that. First for 3.3 (beware, cutnpaste, with most trailing \\n edited out I hope): Command: /mnt/misca2/builds/gcc33/bug2/gcc/xgcc -B/mnt/misca2/builds/gcc33/bug2/gcc/ -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/ -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/lib/ -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/hp/cvs_areas/combined/cvs_write33/gcc -I/home/hp/cvs_areas/combined/cvs_write33/gcc/. -I/home/hp/cvs_areas/combined/cvs_write33/gcc/config -I/home/hp/cvs_areas/combined/cvs_write33/gcc/../include -DL_fixunsdfsi -c /home/hp/cvs_areas/combined/cvs_write33/gcc/libgcc2.c -o libgcc/./_fixunsdfsi.o -v Output: Reading specs from /mnt/misca2/builds/gcc33/bug2/gcc/specs Configured with: /home/hp/cvs_areas/combined/cvs_write33/configure --target=cris-linux --prefix=/home/hp/work/axis/build/gcc3testprefix Thread model: posix gcc version 3.3 20030216 (prerelease) /mnt/misca2/builds/gcc33/bug2/gcc/cc1 -quiet -v -I. -I. -I/home/hp/cvs_areas/combined/cvs_write33/gcc -I/home/hp/cvs_areas/combined/cvs_write33/gcc/. -I/home/hp/cvs_areas/combined/cvs_write33/gcc/config -I/home/hp/cvs_areas/combined/cvs_write33/gcc/../include -iprefix /mnt/misca2/builds/gcc33/bug2/gcc/../lib/gcc-lib/cris-linux/3.3/ -isystem /mnt/misca2/builds/gcc33/bug2/gcc/include -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/include -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/lib/include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -Dcris -DCRIS -DGNU_CRIS -D__cris__ -D__CRIS__ -D__GNU_CRIS__ -D__cris -D__CRIS -D__GNU_CRIS -D__CRIS_ABI_version=2 -D__arch_v10 -D__CRIS_arch_version=10 -Dlinux -Dunix -Asystem(unix) -Asystem(posix) -Acpu(cris) -Amachine(cris) -DIN_GCC -DCROSS_COMPILE -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -DL_fixunsdfsi -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/in! clude -isystem ./include /home/hp/cvs_areas/combined/cvs_write33/gcc/libgcc2.c -march=v10 -quiet -dumpbase libgcc2.c -auxbase-strip libgcc/./_fixunsdfsi.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -version -fPIC -o /usr/tmp/ccRkOKzI.s ignoring nonexistent directory "/home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/include" ignoring nonexistent directory "/home/hp/work/axis/build/gcc3testprefix/cris-linux/lib/include" ignoring nonexistent directory "/home/hp/work/axis/build/gcc3testprefix/cris-linux/include" GNU C version 3.3 20030216 (prerelease) (cris-linux) compiled by GNU C version 2.95.3 20010315 (release). ignoring nonexistent directory "/mnt/misca2/builds/gcc33/bug2/lib/gcc-lib/cris-linux/3.3/include" ignoring nonexistent directory "/mnt/misca2/builds/gcc33/bug2/lib/gcc-lib/cris-linux/3.3/../../../../cris-linux/sys-include" ignoring nonexistent directory "/mnt/misca2/builds/gcc33/bug2/lib/gcc-lib/cris-linux/3.3/../../../../cris-linux/include" ignoring nonexistent directory "/home/hp/work/axis/build/gcc3testprefix/include" ignoring nonexistent directory "/home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris-linux/3.3/include" ignoring nonexistent directory "/home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris-linux/3.3/../../../../cris-linux/include " ignoring duplicate directory "." ignoring duplicate directory "/home/hp/cvs_areas/combined/cvs_write33/gcc" ignoring duplicate directory "include" #include "..." search starts here: #include <...> search starts here: . /home/hp/cvs_areas/combined/cvs_write33/gcc /home/hp/cvs_areas/combined/cvs_write33/gcc/config /home/hp/cvs_areas/combined/cvs_write33/include /mnt/misca2/builds/gcc33/bug2/gcc/include /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris-linux/3.3/../../../../cris-linux/sys-include End of search list. /home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/as --traditional-format -v --em=criself --no-underscore --pic -o libgcc/./_fixunsdfsi.o /usr/tmp/ccRkOKzI.s GNU assembler version 2.12.1 (cris) using BFD version 2.12.1 > and HEAD? With "&& !defined (TARGET_SYSTEM_ROOT)" in cppdefaults.h taken out, I assume. Otherwise it picks up headers from /usr/local/include. With that change: Command: /mnt/miscb3/builds2/bug2/gcc/xgcc -B/mnt/miscb3/builds2/bug2/gcc/ -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/ -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/lib/ -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/hp/cvs_areas/combined/cvs_write/gcc -I/home/hp/cvs_areas/combined/cvs_write/gcc/. -I/home/hp/cvs_areas/combined/cvs_write/gcc/config -I/home/hp/cvs_areas/combined/cvs_write/gcc/../include -DL_fixunsdfsi -c /home/hp/cvs_areas/combined/cvs_write/gcc/libgcc2.c -o libgcc/./_fixunsdfsi.o -v Output, in which you see the failure mode: Reading specs from /mnt/miscb3/builds2/bug2/gcc/specs Configured with: /home/hp/cvs_areas/combined/cvs_write/configure --target=cris-linux --prefix=/home/hp/work/axis/build/gcc3testprefix Thread model: posix gcc version 3.4 20030219 (experimental) /mnt/miscb3/builds2/bug2/gcc/cc1 -quiet -v -I. -I. -I/home/hp/cvs_areas/combined/cvs_write/gcc -I/home/hp/cvs_areas/combined/cvs_write/gcc/. -I/home/hp/cvs_areas/combined/cvs_write/gcc/config -I/home/hp/cvs_areas/combined/cvs_write/gcc/../include -iprefix /mnt/miscb3/builds2/bug2/gcc/../lib/gcc-lib/cris-linux/3.4/ -isystem /mnt/miscb3/builds2/bug2/gcc/include -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/include -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/lib/include -D__GNUC__=3 -D__GNUC_MINOR__=4 -D__GNUC_PATCHLEVEL__=0 -Dcris -DCRIS -DGNU_CRIS -D__cris__ -D__CRIS__ -D__GNU_CRIS__ -D__cris -D__CRIS -D__GNU_CRIS -D__CRIS_ABI_version=2 -D__arch_v10 -D__CRIS_arch_version=10 -Dlinux -Dunix -Asystem(unix) -Asystem(posix) -Acpu(cris) -Amachine(cris) -DIN_GCC -DCROSS_COMPILE -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -DL_fixunsdfsi -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/include -isystem ./includ! e /home/hp/cvs_areas/combined/cvs_write/gcc/libgcc2.c -march=v10 -quiet -dumpbase libgcc2.c -auxbase-strip libgcc/./_fixunsdfsi.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -version -fPIC -o /usr/tmp/ccLaSv0R.s ignoring nonexistent directory "/home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/include" ignoring nonexistent directory "/home/hp/work/axis/build/gcc3testprefix/cris-linux/lib/include" ignoring nonexistent directory "/home/hp/work/axis/build/gcc3testprefix/cris-linux/include" GNU C version 3.4 20030219 (experimental) (cris-linux) compiled by GNU C version 2.95.3 20010315 (release). ignoring nonexistent directory "/mnt/miscb3/builds2/bug2/lib/gcc-lib/cris-linux/3.4/include" ignoring nonexistent directory "/mnt/miscb3/builds2/bug2/lib/gcc-lib/cris-linux/3.4/../../../../cris-linux/sys-include" ignoring nonexistent directory "/mnt/miscb3/builds2/bug2/lib/gcc-lib/cris-linux/3.4/../../../../cris-linux/include" ignoring duplicate directory "." ignoring duplicate directory "/home/hp/cvs_areas/combined/cvs_write/gcc" ignoring duplicate directory "include" #include "..." search starts here: #include <...> search starts here: . /home/hp/cvs_areas/combined/cvs_write/gcc /home/hp/cvs_areas/combined/cvs_write/gcc/config /home/hp/cvs_areas/combined/cvs_write/include /mnt/miscb3/builds2/bug2/gcc/include End of search list. In file included from /mnt/miscb3/builds2/bug2/gcc/include/syslimits.h:7, from /mnt/miscb3/builds2/bug2/gcc/include/limits.h:11, from /home/hp/cvs_areas/combined/cvs_write/gcc/libgcc2.c:1336: /mnt/miscb3/builds2/bug2/gcc/include/limits.h:122:75: no include path in which to find limits.h > You said thre were "a couple of symlinks" involved - what > others? Nothing I can see would be of interest. Did you change ../-symlink handling too? Here's an edited ls -lR /home/hp/work/axis/build/gcc3testprefix. I edited out some stuff. I'm not going to send the raw version, it's just too cruddy. I'll rather look at your sysroot patches to see if I can spot the bug. /home/hp/work/axis/build/gcc3testprefix: total 12 drwxr-xr-x 3 hp hp 4096 Sep 15 2001 bin lrwxrwxrwx 1 hp hp 30 Jan 10 22:00 cris-axis-aout -> /usr/local/cris/cris-axis-aout lrwxrwxrwx 1 hp hp 29 Jan 10 22:00 cris-axis-elf -> /usr/local/cris/cris-axis-elf lrwxrwxrwx 1 hp hp 35 Jan 10 22:00 cris-axis-linux-gnu -> /usr/local/cris/cris-axis-linux-gnu lrwxrwxrwx 1 hp hp 29 Jan 13 03:16 cris-elf -> /usr/local/cris/cris-axis-elf lrwxrwxrwx 1 hp hp 35 Jan 13 03:16 cris-linux -> /usr/local/cris/cris-axis-linux-gnu drwxr-xr-x 3 hp hp 4096 Feb 20 15:31 lib /home/hp/work/axis/build/gcc3testprefix/bin: total 20 lrwxrwxrwx 1 hp hp 64 Sep 13 2001 ar-cris -> /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris/2.96/ar lrwxrwxrwx 1 hp hp 64 Sep 13 2001 as-cris -> /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris/2.96/as lrwxrwxrwx 1 hp hp 64 Sep 13 2001 cris-ld -> /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris/2.96/ld lrwxrwxrwx 1 hp hp 64 Sep 13 2001 cris-nm -> /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris/2.96/nm *** Similar unused binutils links edited out. /home/hp/work/axis/build/gcc3testprefix/lib: total 4 drwxr-xr-x 5 hp hp 4096 Sep 23 2001 gcc-lib /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib: total 12 drwxr-xr-x 4 hp hp 4096 Jan 14 05:18 cris drwxrwxr-x 2 hp hp 4096 Jan 10 21:58 cris-aout lrwxrwxrwx 1 hp hp 4 Sep 22 2001 cris-elf -> cris drwxrwxr-x 3 hp hp 4096 Jan 14 03:12 cris-linux /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris: *** Nah, that's not used for cris-axis-linux-gnu and full of crud. /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris-aout: *** Ditto /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris-linux: total 4 drwxrwxr-x 2 hp hp 4096 Jan 14 03:12 3.1 lrwxrwxrwx 1 hp hp 3 Dec 17 10:25 3.2.3 -> 3.1 lrwxrwxrwx 1 hp hp 3 Dec 17 10:25 3.3 -> 3.1 lrwxrwxrwx 1 hp hp 3 Dec 17 10:25 3.4 -> 3.1 *** more symlinks lrwxrwxrwx 1 hp hp 35 Jan 14 02:16 as -> ../../../cris-axis-linux-gnu/bin/as lrwxrwxrwx 1 hp hp 35 Jan 14 02:16 ld -> ../../../cris-axis-linux-gnu/bin/ld lrwxrwxrwx 1 hp hp 35 Jan 14 02:16 nm -> ../../../cris-axis-linux-gnu/bin/nm lrwxrwxrwx 1 hp hp 38 Jan 14 02:16 strip -> ../../../cris-axis-linux-gnu/bin/strip lrwxrwxrwx 1 hp hp 40 Jan 14 03:01 sys-include -> ../../../cris-axis-linux-gnu/sys-include /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris-linux/3.1: total 0 > For instance do you use a symlink to the gcc binary? No, that's exactly the kind of thing I want to avoid. :-) As seen above, just a relatively-empty cruddy prefix tree with symlinks to binutils, libraries and header files, avoiding anything explicit or implicit paths to anything installed by gcc. (For the audience: No, I don't recommend it, so I don't want to document it in some howto -- people should start using sysroot instead. :-) brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-20 16:24 ` Hans-Peter Nilsson @ 2003-02-20 18:49 ` Daniel Jacobowitz 2003-02-20 20:21 ` Hans-Peter Nilsson 2003-03-03 17:04 ` Daniel Jacobowitz 0 siblings, 2 replies; 18+ messages in thread From: Daniel Jacobowitz @ 2003-02-20 18:49 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches On Thu, Feb 20, 2003 at 05:24:43PM +0100, Hans-Peter Nilsson wrote: > > Date: Thu, 20 Feb 2003 10:16:01 -0500 > > From: Daniel Jacobowitz <drow@mvista.com> > > On Thu, Feb 20, 2003 at 04:09:41PM +0100, Hans-Peter Nilsson wrote: > > > 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. > > > > Better report. Could you give me the output of gcc -v for 3.3-branch I think I see the problem. > Compiling fixunsdfsi is where it fails, so I'll show that. > First for 3.3 (beware, cutnpaste, with most trailing \\n edited > out I hope): > > Command: > /mnt/misca2/builds/gcc33/bug2/gcc/xgcc -B/mnt/misca2/builds/gcc33/bug2/gcc/ -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/ -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/lib/ -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/hp/cvs_areas/combined/cvs_write33/gcc -I/home/hp/cvs_areas/combined/cvs_write33/gcc/. -I/home/hp/cvs_areas/combined/cvs_write33/gcc/config -I/home/hp/cvs_areas/combined/cvs_write33/gcc/../include -DL_fixunsdfsi -c /home/hp/cvs_areas/combined/cvs_write33/gcc/libgcc2.c -o libgcc/./_fixunsdfsi.o -v > > Output: > /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris-linux/3.3/../../../../cris-linux/sys-include Look at the command and the resulting search directory. The directory is relative to $prefix, that is, the final installation directory. But the compiler isn't there now. One part of my changes, which I consider a strict correctness change, is that if we would search a relocated copy of a directory (based on where the gcc binary is) then we should not search the unrelocated copy (based on $prefix, which doesn't apply, because we aren't there right now). Now we do: > Command: > /mnt/miscb3/builds2/bug2/gcc/xgcc -B/mnt/miscb3/builds2/bug2/gcc/ -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/ -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/lib/ -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/hp/cvs_areas/combined/cvs_write/gcc -I/home/hp/cvs_areas/combined/cvs_write/gcc/. -I/home/hp/cvs_areas/combined/cvs_write/gcc/config -I/home/hp/cvs_areas/combined/cvs_write/gcc/../include -DL_fixunsdfsi -c /home/hp/cvs_areas/combined/cvs_write/gcc/libgcc2.c -o libgcc/./_fixunsdfsi.o -v > > Output, in which you see the failure mode: > ignoring nonexistent directory "/mnt/miscb3/builds2/bug2/lib/gcc-lib/cris-linux/3.4/include" > ignoring nonexistent directory "/mnt/miscb3/builds2/bug2/lib/gcc-lib/cris-linux/3.4/../../../../cris-linux/sys-include" We see that the binary is in the build dir, so we're searching in the build dir for $prefix/cris-linux/sys-include. So we need to either: - not relocate sys-include, seems like a bad idea - explicitly specify it at build time as an additional -I option -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-20 18:49 ` Daniel Jacobowitz @ 2003-02-20 20:21 ` Hans-Peter Nilsson 2003-03-03 17:04 ` Daniel Jacobowitz 1 sibling, 0 replies; 18+ messages in thread From: Hans-Peter Nilsson @ 2003-02-20 20:21 UTC (permalink / raw) To: drow; +Cc: hans-peter.nilsson, gcc-patches > Date: Thu, 20 Feb 2003 13:49:39 -0500 > From: Daniel Jacobowitz <drow@mvista.com> > Look at the command and the resulting search directory. The directory > is relative to $prefix, that is, the final installation directory. But > the compiler isn't there now. One part of my changes, which I > consider a strict correctness change, is that if we would search a > relocated copy of a directory (based on where the gcc binary is) then > we should not search the unrelocated copy (based on $prefix, which > doesn't apply, because we aren't there right now). Ah. Ok. I'm not really sure I agree that relocation should not be attempted in this case, but I see you can make a case against it. > So we need to either: > - not relocate sys-include, seems like a bad idea Agreed. > - explicitly specify it at build time as an additional -I option Agree, except you want "-isystem", not "-I" ;-) brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-20 18:49 ` Daniel Jacobowitz 2003-02-20 20:21 ` Hans-Peter Nilsson @ 2003-03-03 17:04 ` Daniel Jacobowitz 2003-03-04 19:18 ` Alexandre Oliva 1 sibling, 1 reply; 18+ messages in thread From: Daniel Jacobowitz @ 2003-03-03 17:04 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches, dj, aoliva On Thu, Feb 20, 2003 at 01:49:39PM -0500, Daniel Jacobowitz wrote: > On Thu, Feb 20, 2003 at 05:24:43PM +0100, Hans-Peter Nilsson wrote: > > > Date: Thu, 20 Feb 2003 10:16:01 -0500 > > > From: Daniel Jacobowitz <drow@mvista.com> > > > On Thu, Feb 20, 2003 at 04:09:41PM +0100, Hans-Peter Nilsson wrote: > > > > 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. > > > > > > Better report. Could you give me the output of gcc -v for 3.3-branch > > I think I see the problem. > > > Compiling fixunsdfsi is where it fails, so I'll show that. > > First for 3.3 (beware, cutnpaste, with most trailing \\n edited > > out I hope): > > > > Command: > > /mnt/misca2/builds/gcc33/bug2/gcc/xgcc -B/mnt/misca2/builds/gcc33/bug2/gcc/ -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/ -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/lib/ -isystem /home/hp/work/axis/build/gcc3testprefix/cris-linux/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/hp/cvs_areas/combined/cvs_write33/gcc -I/home/hp/cvs_areas/combined/cvs_write33/gcc/. -I/home/hp/cvs_areas/combined/cvs_write33/gcc/config -I/home/hp/cvs_areas/combined/cvs_write33/gcc/../include -DL_fixunsdfsi -c /home/hp/cvs_areas/combined/cvs_write33/gcc/libgcc2.c -o libgcc/./_fixunsdfsi.o -v > > > > Output: > > > /home/hp/work/axis/build/gcc3testprefix/lib/gcc-lib/cris-linux/3.3/../../../../cris-linux/sys-include > > Look at the command and the resulting search directory. The directory > is relative to $prefix, that is, the final installation directory. But > the compiler isn't there now. One part of my changes, which I > consider a strict correctness change, is that if we would search a > relocated copy of a directory (based on where the gcc binary is) then > we should not search the unrelocated copy (based on $prefix, which > doesn't apply, because we aren't there right now). > > Now we do: > > > Command: /mnt/miscb3/builds2/bug2/gcc/xgcc > > -B/mnt/miscb3/builds2/bug2/gcc/ > > -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/bin/ > > -B/home/hp/work/axis/build/gcc3testprefix/cris-linux/lib/ -isystem > > /home/hp/work/axis/build/gcc3testprefix/cris-linux/include -O2 > > -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings > > -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC > > -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED > > -Dinhibit_libc -I. -I. -I/home/hp/cvs_areas/combined/cvs_write/gcc > > -I/home/hp/cvs_areas/combined/cvs_write/gcc/. > > -I/home/hp/cvs_areas/combined/cvs_write/gcc/config > > -I/home/hp/cvs_areas/combined/cvs_write/gcc/../include > > -DL_fixunsdfsi -c > > /home/hp/cvs_areas/combined/cvs_write/gcc/libgcc2.c -o > > libgcc/./_fixunsdfsi.o -v > > > > Output, in which you see the failure mode: > > ignoring nonexistent directory "/mnt/miscb3/builds2/bug2/lib/gcc-lib/cris-linux/3.4/include" > > ignoring nonexistent directory "/mnt/miscb3/builds2/bug2/lib/gcc-lib/cris-linux/3.4/../../../../cris-linux/sys-include" > > We see that the binary is in the build dir, so we're searching in the > build dir for $prefix/cris-linux/sys-include. I was looking this over today, because I wanted to fix it before I checked in a fix to the other problem. I couldn't reproduce it at first. You get three -B options and one -isystem at the beginning of your command line building libgcc; but when I configure in the same way, I get: -B./ -B/big/fsf/local/cross-test/prefix/mipsel-linux/bin/ -isystem /big/fsf/local/cross-test/prefix/mipsel-linux/include -isystem /big/fsf/local/cross-test/prefix/mipsel-linux/sys-include That's from GCC_FOR_TARGET. It turns out that I was impatient, so I just ran make in the gcc directory; but GCC_FOR_TARGET is _different_ in the GCC makefile from in the toplevel makefile. I bet that if you (cd gcc; make) after the error above, it'll build OK. I think just fixing the toplevel GCC_FOR_TARGET is in order; here's a minimalist solution. DJ or Alex, is this patch OK? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ./ 2003-03-03 Daniel Jacobowitz <drow@mvista.com> * configure.in: Include $(build_tooldir)/sys-include in FLAGS_FOR_TARGET. * configure: Regenerated. gcc/ 2003-03-03 Daniel Jacobowitz <drow@mvista.com> * configure.in: Don't always define TARGET_SYSTEM_ROOT. * configure: Regenerated. * gcc.c: Check whether TARGET_SYSTEM_ROOT is defined. Index: configure =================================================================== RCS file: /big/fsf/rsync/gcc-cvs/gcc/configure,v retrieving revision 1.76 diff -u -p -r1.76 configure --- configure 16 Feb 2003 01:09:27 -0000 1.76 +++ configure 3 Mar 2003 16:53:36 -0000 @@ -2594,7 +2594,7 @@ esac # being built; programs in there won't even run. if test "${build}" = "${host}" && test -d ${srcdir}/gcc; then # Search for pre-installed headers if nothing else fits. - FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include' + FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include' fi if test "x${use_gnu_ld}" = x && Index: configure.in =================================================================== RCS file: /big/fsf/rsync/gcc-cvs/gcc/configure.in,v retrieving revision 1.220 diff -u -p -r1.220 configure.in --- configure.in 16 Feb 2003 01:09:27 -0000 1.220 +++ configure.in 3 Mar 2003 16:52:52 -0000 @@ -1936,7 +1936,7 @@ esac # being built; programs in there won't even run. if test "${build}" = "${host}" && test -d ${srcdir}/gcc; then # Search for pre-installed headers if nothing else fits. - FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include' + FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/ -B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include' fi if test "x${use_gnu_ld}" = x && Index: gcc/configure =================================================================== RCS file: /big/fsf/rsync/gcc-cvs/gcc/gcc/configure,v retrieving revision 1.658 diff -u -p -r1.658 configure --- gcc/configure 14 Feb 2003 17:28:54 -0000 1.658 +++ gcc/configure 3 Mar 2003 16:12:16 -0000 @@ -2299,7 +2299,7 @@ if test "${with_sysroot+set}" = set; the else TARGET_SYSTEM_ROOT= - TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=0' + TARGET_SYSTEM_ROOT_DEFINE= CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include' fi Index: gcc/configure.in =================================================================== RCS file: /big/fsf/rsync/gcc-cvs/gcc/gcc/configure.in,v retrieving revision 1.643 diff -u -p -r1.643 configure.in --- gcc/configure.in 14 Feb 2003 17:28:55 -0000 1.643 +++ gcc/configure.in 3 Mar 2003 16:12:16 -0000 @@ -514,7 +514,7 @@ AC_ARG_WITH(sysroot, esac ], [ TARGET_SYSTEM_ROOT= - TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=0' + TARGET_SYSTEM_ROOT_DEFINE= CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include' ]) AC_SUBST(TARGET_SYSTEM_ROOT) Index: gcc/gcc.c =================================================================== RCS file: /big/fsf/rsync/gcc-cvs/gcc/gcc/gcc.c,v retrieving revision 1.361 diff -u -p -r1.361 gcc.c --- gcc/gcc.c 13 Feb 2003 17:23:56 -0000 1.361 +++ gcc/gcc.c 3 Mar 2003 16:12:16 -0000 @@ -202,7 +202,11 @@ static int report_times; /* Nonzero means place this string before uses of /, so that include and library files can be found in an alternate location. */ +#ifdef TARGET_SYSTEM_ROOT static const char *target_system_root = TARGET_SYSTEM_ROOT; +#else +static const char *target_system_root = 0; +#endif /* Nonzero means pass the updated target_system_root to the compiler. */ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-03-03 17:04 ` Daniel Jacobowitz @ 2003-03-04 19:18 ` Alexandre Oliva 0 siblings, 0 replies; 18+ messages in thread From: Alexandre Oliva @ 2003-03-04 19:18 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Hans-Peter Nilsson, gcc-patches, dj On Mar 3, 2003, Daniel Jacobowitz <drow@mvista.com> wrote: > 2003-03-03 Daniel Jacobowitz <drow@mvista.com> > * configure.in: Include $(build_tooldir)/sys-include in > FLAGS_FOR_TARGET. > * configure: Regenerated. > gcc/ > 2003-03-03 Daniel Jacobowitz <drow@mvista.com> > * configure.in: Don't always define TARGET_SYSTEM_ROOT. > * configure: Regenerated. Ok. > * gcc.c: Check whether TARGET_SYSTEM_ROOT is defined. I'm not sure I can approve this, but along with the above, it can probably go in as obvious :-) Thanks. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-20 15:09 Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken Hans-Peter Nilsson 2003-02-20 15:16 ` Daniel Jacobowitz @ 2003-02-20 19:09 ` Daniel Jacobowitz 2003-02-20 20:36 ` Hans-Peter Nilsson 2003-02-22 2:05 ` Hans-Peter Nilsson 1 sibling, 2 replies; 18+ messages in thread From: Daniel Jacobowitz @ 2003-02-20 19:09 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches On Thu, Feb 20, 2003 at 04:09:41PM +0100, Hans-Peter Nilsson wrote: > (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. For this problem, could you try out the following patch? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 2003-02-20 Daniel Jacobowitz <drow@mvista.com> * configure.in: Don't always define TARGET_SYSTEM_ROOT. * configure: Regenerated. * gcc.c: Check whether TARGET_SYSTEM_ROOT is defined. Index: configure =================================================================== RCS file: /big/fsf/rsync/gcc-cvs/gcc/gcc/configure,v retrieving revision 1.658 diff -u -p -r1.658 configure --- configure 14 Feb 2003 17:28:54 -0000 1.658 +++ configure 20 Feb 2003 19:06:54 -0000 @@ -2299,7 +2299,7 @@ if test "${with_sysroot+set}" = set; the else TARGET_SYSTEM_ROOT= - TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=0' + TARGET_SYSTEM_ROOT_DEFINE= CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include' fi Index: configure.in =================================================================== RCS file: /big/fsf/rsync/gcc-cvs/gcc/gcc/configure.in,v retrieving revision 1.643 diff -u -p -r1.643 configure.in --- configure.in 14 Feb 2003 17:28:55 -0000 1.643 +++ configure.in 20 Feb 2003 19:05:31 -0000 @@ -514,7 +514,7 @@ AC_ARG_WITH(sysroot, esac ], [ TARGET_SYSTEM_ROOT= - TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=0' + TARGET_SYSTEM_ROOT_DEFINE= CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include' ]) AC_SUBST(TARGET_SYSTEM_ROOT) Index: gcc.c =================================================================== RCS file: /big/fsf/rsync/gcc-cvs/gcc/gcc/gcc.c,v retrieving revision 1.362 diff -u -p -r1.362 gcc.c --- gcc.c 18 Feb 2003 18:19:09 -0000 1.362 +++ gcc.c 20 Feb 2003 19:06:18 -0000 @@ -202,7 +202,11 @@ static int report_times; /* Nonzero means place this string before uses of /, so that include and library files can be found in an alternate location. */ +#ifdef TARGET_SYSTEM_ROOT static const char *target_system_root = TARGET_SYSTEM_ROOT; +#else +static const char *target_system_root = 0; +#endif /* Nonzero means pass the updated target_system_root to the compiler. */ ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-20 19:09 ` Daniel Jacobowitz @ 2003-02-20 20:36 ` Hans-Peter Nilsson 2003-02-22 2:05 ` Hans-Peter Nilsson 1 sibling, 0 replies; 18+ messages in thread From: Hans-Peter Nilsson @ 2003-02-20 20:36 UTC (permalink / raw) To: drow; +Cc: hans-peter.nilsson, gcc-patches > Date: Thu, 20 Feb 2003 14:09:13 -0500 > From: Daniel Jacobowitz <drow@mvista.com> > On Thu, Feb 20, 2003 at 04:09:41PM +0100, Hans-Peter Nilsson wrote: > > 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. > > For this problem, could you try out the following patch? Umm, I have to limit that verification up to the second failure; that your fix is equivalent to taking out the "&& !defined (TARGET_SYSTEM_ROOT)" in cppdefaults.h. I'll do that ASAP. brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-20 19:09 ` Daniel Jacobowitz 2003-02-20 20:36 ` Hans-Peter Nilsson @ 2003-02-22 2:05 ` Hans-Peter Nilsson 2003-02-22 3:56 ` Daniel Jacobowitz 1 sibling, 1 reply; 18+ messages in thread From: Hans-Peter Nilsson @ 2003-02-22 2:05 UTC (permalink / raw) To: drow; +Cc: hans-peter.nilsson, gcc-patches > Date: Thu, 20 Feb 2003 14:09:13 -0500 > From: Daniel Jacobowitz <drow@mvista.com> > On Thu, Feb 20, 2003 at 04:09:41PM +0100, Hans-Peter Nilsson wrote: > > 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. > > For this problem, could you try out the following patch? I can confirm that it works as expected. Thanks! Do you have a patch for the second problem? ...hum, maybe I should fix my setup to not require relocation. I'll do that, but I'm still uneasy about the changed relocation semantics (not relocating when the gcc binary is elsewhere). Was that discussed and agreed on? brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-22 2:05 ` Hans-Peter Nilsson @ 2003-02-22 3:56 ` Daniel Jacobowitz 2003-02-22 4:12 ` Hans-Peter Nilsson 0 siblings, 1 reply; 18+ messages in thread From: Daniel Jacobowitz @ 2003-02-22 3:56 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches On Sat, Feb 22, 2003 at 03:05:27AM +0100, Hans-Peter Nilsson wrote: > > Date: Thu, 20 Feb 2003 14:09:13 -0500 > > From: Daniel Jacobowitz <drow@mvista.com> > > > On Thu, Feb 20, 2003 at 04:09:41PM +0100, Hans-Peter Nilsson wrote: > > > 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. > > > > For this problem, could you try out the following patch? > > I can confirm that it works as expected. Thanks! Do you have a > patch for the second problem? No, but it should be a matter of an -isystem somewhere. > ...hum, maybe I should fix my setup to not require relocation. > I'll do that, but I'm still uneasy about the changed relocation > semantics (not relocating when the gcc binary is elsewhere). > Was that discussed and agreed on? I don't understand what change you mean. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-22 3:56 ` Daniel Jacobowitz @ 2003-02-22 4:12 ` Hans-Peter Nilsson 2003-02-22 4:25 ` Daniel Jacobowitz 0 siblings, 1 reply; 18+ messages in thread From: Hans-Peter Nilsson @ 2003-02-22 4:12 UTC (permalink / raw) To: drow; +Cc: hans-peter.nilsson, gcc-patches > Date: Fri, 21 Feb 2003 22:55:55 -0500 > From: Daniel Jacobowitz <drow@mvista.com> > On Sat, Feb 22, 2003 at 03:05:27AM +0100, Hans-Peter Nilsson wrote: > > I can confirm that it works as expected. Thanks! Do you have a > > patch for the second problem? > > No, but it should be a matter of an -isystem somewhere. I changed my setup instead. > > ...hum, maybe I should fix my setup to not require relocation. > > I'll do that, but I'm still uneasy about the changed relocation > > semantics (not relocating when the gcc binary is elsewhere). > > Was that discussed and agreed on? > > I don't understand what change you mean. Look at previous emails, same thread. You changed implementation semantics so that calling gcc from outside the installation prefix, for example as /foo/build/gcc/xgcc, now results in include-paths at it's configured --prefix will not get ../-relocated. You said it was a matter of correctness. I'm not so sure, therefore I ask if that change was really agreed to by the approver. brgds, H-P ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-22 4:12 ` Hans-Peter Nilsson @ 2003-02-22 4:25 ` Daniel Jacobowitz 2003-03-04 19:20 ` Alexandre Oliva 0 siblings, 1 reply; 18+ messages in thread From: Daniel Jacobowitz @ 2003-02-22 4:25 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: gcc-patches On Sat, Feb 22, 2003 at 05:12:34AM +0100, Hans-Peter Nilsson wrote: > > Date: Fri, 21 Feb 2003 22:55:55 -0500 > > From: Daniel Jacobowitz <drow@mvista.com> > > On Sat, Feb 22, 2003 at 03:05:27AM +0100, Hans-Peter Nilsson wrote: > > > I can confirm that it works as expected. Thanks! Do you have a > > > patch for the second problem? > > > > No, but it should be a matter of an -isystem somewhere. > > I changed my setup instead. OK, but I think I still need to fix it. I'll investigate a little more tomorrow. I don't want to break old setups. > > > ...hum, maybe I should fix my setup to not require relocation. > > > I'll do that, but I'm still uneasy about the changed relocation > > > semantics (not relocating when the gcc binary is elsewhere). > > > Was that discussed and agreed on? > > > > I don't understand what change you mean. > > Look at previous emails, same thread. You changed > implementation semantics so that calling gcc from outside the > installation prefix, for example as /foo/build/gcc/xgcc, now > results in include-paths at it's configured --prefix will not > get ../-relocated. You said it was a matter of correctness. > I'm not so sure, therefore I ask if that change was really > agreed to by the approver. I don't think that's what I said. The change was that when you run gcc from outside the installation prefix, nothing inside the installation prefix will be searched. We've had bug reports about this in the past; it's really quite important. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-02-22 4:25 ` Daniel Jacobowitz @ 2003-03-04 19:20 ` Alexandre Oliva 2003-03-04 19:25 ` Daniel Jacobowitz 0 siblings, 1 reply; 18+ messages in thread From: Alexandre Oliva @ 2003-03-04 19:20 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Hans-Peter Nilsson, gcc-patches On Feb 22, 2003, Daniel Jacobowitz <drow@mvista.com> wrote: > The change was that when you run gcc > from outside the installation prefix, nothing inside the installation > prefix will be searched. Not even the original (unrelocated) installation prefix? This sounds wrong to me. If I read you correctly, this means that the sys-root isn't searched during the GCC build process. Is this the effect of your change? If so, I don't agree it's the right thing to do. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-03-04 19:20 ` Alexandre Oliva @ 2003-03-04 19:25 ` Daniel Jacobowitz 2003-03-04 21:18 ` Alexandre Oliva 0 siblings, 1 reply; 18+ messages in thread From: Daniel Jacobowitz @ 2003-03-04 19:25 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Hans-Peter Nilsson, gcc-patches On Tue, Mar 04, 2003 at 04:19:11PM -0300, Alexandre Oliva wrote: > On Feb 22, 2003, Daniel Jacobowitz <drow@mvista.com> wrote: > > > The change was that when you run gcc > > from outside the installation prefix, nothing inside the installation > > prefix will be searched. > > Not even the original (unrelocated) installation prefix? This sounds > wrong to me. If I read you correctly, this means that the sys-root > isn't searched during the GCC build process. Is this the effect of > your change? If so, I don't agree it's the right thing to do. In theory it could mean that, but there's something else involved that we discussed: we only relocate the sysroot if (the sysroot was inside the prefix and) the new directory would exist. If you happen to have something matching the sysroot location from inside the build tree, then I assume it's deliberate. This is pretty important. Consider: /opt/manufacturer/bin/gcc /opt/manufacturer/target/usr/include/version2.h /opt/manufacturer-old/bin/gcc /opt/manufacturer-old/target/usr/include/version1.h I believe that (even though both were configured for /opt/manufacturer), the one in /opt/manufacturer-old should not search there and autoconf checks for version2.h should fail. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-03-04 19:25 ` Daniel Jacobowitz @ 2003-03-04 21:18 ` Alexandre Oliva 2003-03-04 21:32 ` Daniel Jacobowitz 0 siblings, 1 reply; 18+ messages in thread From: Alexandre Oliva @ 2003-03-04 21:18 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Hans-Peter Nilsson, gcc-patches On Mar 4, 2003, Daniel Jacobowitz <drow@mvista.com> wrote: > On Tue, Mar 04, 2003 at 04:19:11PM -0300, Alexandre Oliva wrote: >> On Feb 22, 2003, Daniel Jacobowitz <drow@mvista.com> wrote: >> > The change was that when you run gcc >> > from outside the installation prefix, nothing inside the installation >> > prefix will be searched. >> Not even the original (unrelocated) installation prefix? This sounds >> wrong to me. If I read you correctly, this means that the sys-root >> isn't searched during the GCC build process. Is this the effect of >> your change? If so, I don't agree it's the right thing to do. > In theory it could mean that, but there's something else involved that > we discussed: we only relocate the sysroot if (the sysroot was inside > the prefix and) the new directory would exist. Note I'm not worried about sysroot relocation atm. I'm worried about GCC not searching the prefix it was configured for before it was installed. The need for the explicit sys-includes in the top level seems to indicate it won't search that directory when started from the build tree. Assuming we have it consistent, I assume the same applies to sys-root/usr/include. I do think that, if GCC can't find the directory it's looking for in the relocated prefix (or, as it happens, in the build tree), it should look at the install prefix. Otherwise, if you build and install binutils, then part of gcc, then newlib, then all of gcc in the same prefix, the gcc build would not find the installed binutils and newlib, which it has always done, and should, IMHO, still do. > I believe that (even though both were configured for > /opt/manufacturer), the one in /opt/manufacturer-old should not search > there and autoconf checks for version2.h should fail. Agreed. If it finds sys-(include|root) in the relocated tree, it should not look for it in the original prefix. If this is the only thing you changed, and it still looks in the original prefix if it can't find the include *directory* in the relocated prefix, I'm happy with it. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-03-04 21:18 ` Alexandre Oliva @ 2003-03-04 21:32 ` Daniel Jacobowitz 2003-03-04 21:58 ` Alexandre Oliva 0 siblings, 1 reply; 18+ messages in thread From: Daniel Jacobowitz @ 2003-03-04 21:32 UTC (permalink / raw) To: Alexandre Oliva; +Cc: Hans-Peter Nilsson, gcc-patches On Tue, Mar 04, 2003 at 06:17:21PM -0300, Alexandre Oliva wrote: > On Mar 4, 2003, Daniel Jacobowitz <drow@mvista.com> wrote: > > > On Tue, Mar 04, 2003 at 04:19:11PM -0300, Alexandre Oliva wrote: > >> On Feb 22, 2003, Daniel Jacobowitz <drow@mvista.com> wrote: > > >> > The change was that when you run gcc > >> > from outside the installation prefix, nothing inside the installation > >> > prefix will be searched. > > >> Not even the original (unrelocated) installation prefix? This sounds > >> wrong to me. If I read you correctly, this means that the sys-root > >> isn't searched during the GCC build process. Is this the effect of > >> your change? If so, I don't agree it's the right thing to do. > > > In theory it could mean that, but there's something else involved that > > we discussed: we only relocate the sysroot if (the sysroot was inside > > the prefix and) the new directory would exist. > > Note I'm not worried about sysroot relocation atm. I'm worried about > GCC not searching the prefix it was configured for before it was > installed. The need for the explicit sys-includes in the top level > seems to indicate it won't search that directory when started from the > build tree. Assuming we have it consistent, I assume the same applies > to sys-root/usr/include. I do think that, if GCC can't find the > directory it's looking for in the relocated prefix (or, as it happens, > in the build tree), it should look at the install prefix. > > Otherwise, if you build and install binutils, then part of gcc, then > newlib, then all of gcc in the same prefix, the gcc build would not > find the installed binutils and newlib, which it has always done, and > should, IMHO, still do. It ought to work correctly. To be honest, I can't be more specific; there are too many active relocation schemes in GCC for me to figure out. > > I believe that (even though both were configured for > > /opt/manufacturer), the one in /opt/manufacturer-old should not search > > there and autoconf checks for version2.h should fail. > > Agreed. If it finds sys-(include|root) in the relocated tree, it > should not look for it in the original prefix. If this is the only > thing you changed, and it still looks in the original prefix if it > can't find the include *directory* in the relocated prefix, I'm happy > with it. For sysroot it does this on the basis of whether it can find the sysroot. For include paths it doesn't; it's not done on a per-directory basis. We already specify the directory that newlib ought to be installing its headers to as an -isystem; I think we have for a long time. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken 2003-03-04 21:32 ` Daniel Jacobowitz @ 2003-03-04 21:58 ` Alexandre Oliva 0 siblings, 0 replies; 18+ messages in thread From: Alexandre Oliva @ 2003-03-04 21:58 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Hans-Peter Nilsson, gcc-patches On Mar 4, 2003, Daniel Jacobowitz <drow@mvista.com> wrote: > We already specify the directory that newlib ought to be installing > its headers to as an -isystem; I think we have for a long time. But only in the GCC subdir, not in the top-level, right? Since I've never built newlib separately from GCC, I can't tell whether this is a change in behavior or not, but since your patch already manages to avoid the problem, we're probably ok. I'll do some testing to make sure. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2003-03-04 21:58 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-02-20 15:09 Bugs in sysroot patches resulting in $(local_include)/include always searched, ../-expansion broken Hans-Peter Nilsson 2003-02-20 15:16 ` Daniel Jacobowitz 2003-02-20 16:24 ` Hans-Peter Nilsson 2003-02-20 18:49 ` Daniel Jacobowitz 2003-02-20 20:21 ` Hans-Peter Nilsson 2003-03-03 17:04 ` Daniel Jacobowitz 2003-03-04 19:18 ` Alexandre Oliva 2003-02-20 19:09 ` Daniel Jacobowitz 2003-02-20 20:36 ` Hans-Peter Nilsson 2003-02-22 2:05 ` Hans-Peter Nilsson 2003-02-22 3:56 ` Daniel Jacobowitz 2003-02-22 4:12 ` Hans-Peter Nilsson 2003-02-22 4:25 ` Daniel Jacobowitz 2003-03-04 19:20 ` Alexandre Oliva 2003-03-04 19:25 ` Daniel Jacobowitz 2003-03-04 21:18 ` Alexandre Oliva 2003-03-04 21:32 ` Daniel Jacobowitz 2003-03-04 21:58 ` Alexandre Oliva
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).