public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* 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 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 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 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-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-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).