Re: cross-builds failing

[Manfred Hollstein <manfred at s-direktnet dot de>]

On Tue, 6 October 1998, 10:09:22, rearnsha@arm.com wrote:

 > 
 > I'm not sure why this has started (or exactly when -- sometime in the last 
 > couple of weeks I think).  I have a cross-build for the ARM set up, with a 
 > gas and newlib tree linked into my source structure.  In the past this has 
 > always built fine (modulo a few small problems with the latest gas 
 > snapshots putting intl in a different place).
 > 
 > Now, trying to build the compiler dies when trying to compile libgcc2.c:
 > 
 > for name in _muldi3 ...; \
 > do \
 >   echo ${name}; \
 >   /home/rearnsha/gnu/egcs/arm-aout/gcc/xgcc -B/home/rearnsha/gnu/egcs/arm-a
 > out/gcc/ -O2 -fomit-frame-pointer  -DCROSS_COMPILE -DIN_GCC  -DSVR4  -g 
 > -O2 -I./include   -I. -I../../../../gnusrc/egcs/gcc 
 > -I../../../../gnusrc/egcs/gcc/config -I../../../../gnusrc/egcs/gcc/../inclu
 > de -c -DL${name} \
 >       ../../../../gnusrc/egcs/gcc/libgcc2.c -o ${name}.o; \
 >   if [ $? -eq 0 ] ; then true; else exit 1; fi; \
 >   /home/rearnsha/gnu/egcs/arm-aout/binutils/ar rc tmplibgcc2.a ${name}.o; \
 >   rm -f ${name}.o; \
 > done
 > _muldi3
 > ../../../../gnusrc/egcs/gcc/libgcc2.c:41: stdlib.h: No such file or 
 > directory
 > ../../../../gnusrc/egcs/gcc/libgcc2.c:42: unistd.h: No such file or 
 > directory
 > gnumake[3]: *** [libgcc2.a] Error 1
 > 
 > I see no mention of newlib in the include path there.
 > 
 > Thinking back, didn't gcc always used to look in <prefix>/<target>/include 
 > ?
 > 
 > Doing a quick test with -v shows it is no-longer doing this.
 > 
 > GNU CPP version egcs-2.92.11 19981002 (gcc2 ss-980609 experimental) 
 > (ARM/semi-hosted)
 > #include "..." search starts here:
 > #include <...> search starts here:
 >  include
 >  .
 >  ../../../../gnusrc/egcs/gcc
 >  ../../../../gnusrc/egcs/gcc/config
 >  ../../../../gnusrc/egcs/gcc/../include
 >  /home/rearnsha/gnu/egcs/arm-aout/gcc/include
 > End of search list.

I guess, this  is  an unfortunate  side-effect of   the $(unlibsubdir)
patch that had been applied  last week.  gcc and  cpp are now using  a
relative path starting from $(libsubdir); since your xgcc isnt't already
installed, $(libsubdir) of course doesn't exist, hence
$(libsubdir)/../../../${target}/include doesn't either.

Jeff,  you mentionened  somewhere, that the  $(unlibsubdir) was mostly
meant to aid the Windoof users; how do you think, if we'll be going to
implement it via a new "--enable-relative-dirs" flag and retain the old
behaviour as a default?

 > 
 > Richard.
 > 

manfred