--sysroot=yes

[Jay <jayk123 at hotmail dot com>]

I think this one is an actual bug, somewhat "predictable" (easy to realize what the problem is roughly),
easy for the appropriate folks to fix, easy for affected folks to workaround.

It goes *like* (this is a paraphrase!): 

  get a "working" system -- cygwin gcc 3.x in my case, but the problem is probably very portable, as long as you don't have an integrated newlib/glibc providing the "sysroot" (e.g. Solaris, djgpp, *bsd?)  
  merged source tree gcc 4.3.1 (release)/binutils 2.18 (release)/gmp/mpfr 
  get a sparc-sun-solaris2.10 sysroot, at /usr/local/sparc-sun-solaris2.10/sys-root  
   This is the default for said target, if you say just -with-sysroot or -with-build-sysroot. 
   The problem is that such defaulting sometimes leads to a value of "yes" instead of the default path.  
  mkdir /obj  
  mkdir /obj/native 
  mkdir /obj/cross   
  mkdir /obj/cross-to-native # what to call this?   
  cd /obj/native 
  /src/gcc/configure && make && make install  
  cd /obj/cross   
  /src/gcc/configure -with-sysroot -host i686-pc-cygwin -target sparc-sun-solaris2.10  && make && make install 
  cd /obj/cross-to-native  
  /src/gcc/configure -with-build-sysroot -host sparc-sun-solaris2.10  -target sparc-sun-solaris2.10  && make && make install DESTDIR=/usr/local/sparc-sun-solaris2.10/install 


Yields:


  make[4]: Entering directory `/obj/gcc.2/sparc-sun-solaris2.10/sparc-sun-solaris2
  .10/sparc-sun-solaris2.10/sparcv9/libgcc'  
  # If this is the top-level multilib, build all the other  
  # multilibs.  
  sparc-sun-solaris2.10-gcc -L/obj/gcc.2/sparc-sun-solaris2.10/sparc-sun-solaris2.  
  10/./ld -O2 -g -g -O2 --sysroot=yes -m64 -O2  -O2 -g -g -O2 --sysroot=yes  -DIN_  
  GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-s  
   tyle-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -  
  D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../../.././gcc -I/src/gcc/libgcc -I/src/gcc/  
  libgcc/. -I/src/gcc/libgcc/../gcc -I/src/gcc/libgcc/../include  -DHAVE_CC_TLS -o  
   _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /src/gcc/libgcc/.  
  ./gcc/libgcc2.c \  
          -fvisibility=hidden -DHIDE_EXPORTS  
  In file included from /src/gcc/libgcc/../gcc/libgcc2.c:33:  
  /src/gcc/libgcc/../gcc/tsystem.h:90:19: error: stdio.h: No such file or director  
  y  
  /src/gcc/libgcc/../gcc/tsystem.h:93:23: error: sys/types.h: No such file or dire  
  ctory  
  /src/gcc/libgcc/../gcc/tsystem.h:96:19: error: errno.h: No such file or director  
  y  
  /src/gcc/libgcc/../gcc/tsystem.h:103:20: error: string.h: No such file or direct  
  ory  
  /src/gcc/libgcc/../gcc/tsystem.h:104:20: error: stdlib.h: No such file or direct  
  ory  
  /src/gcc/libgcc/../gcc/tsystem.h:105:20: error: unistd.h: No such file or direct  
  ory  
  In file included from /usr/local/lib/gcc/sparc-sun-solaris2.10/4.3.1/include-fix  
  ed/syslimits.h:7,  
                 from /usr/local/lib/gcc/sparc-sun-solaris2.10/4.3.1/include-fix  
  ed/limits.h:11,  
                 from /src/gcc/libgcc/../gcc/tsystem.h:108,  
                 from /src/gcc/libgcc/../gcc/libgcc2.c:33:  
  /usr/local/lib/gcc/sparc-sun-solaris2.10/4.3.1/include-fixed/limits.h:122:61: er  
  ror: no include path in which to search for limits.h  
  In file included from /src/gcc/libgcc/../gcc/libgcc2.c:33:  
  /src/gcc/libgcc/../gcc/tsystem.h:111:18: error: time.h: No such file or directory  


 The problem is, if you look closely at the command line, is --sysroot=yes. 
 I configured with just -with-syroot or -with-build-sysroot.


  You can sort of repro it via "emulation", like:  


    /src/gcc/configure -with-sysroot -host i686-pc-cygwin -target sparc-sun-solaris2.10  && make && make install   
    echo "#include "> 1.c   
  
     sparc-sun-solaris2.10-gcc -c 1.c   
     sparc-sun-solaris2.10-gcc --sysroot=yes -c 1.c  


My actual configure commands are a bit longer:

  $ /src/gcc/configure -host i686-pc-cygwin -target sparc-sun-solaris2.10 -verbo
se -without-libiconv-prefix -disable-nls -disable-intl -disable-po -with-gnu-as
-with-gnu-ld -disable-bootstrap -enable-threads -enable-rpath -enable-cld -enabl
e-version-specific-runtime-libs -disable-checking -disable-win32-registry -enabl
e-64-bit-bfd -with-sysroot -enable-languages=c,c++


and

  $ /src/gcc/configure -host sparc-sun-solaris2.10 -target sparc-sun-solaris2.10
 -verbose -without-libiconv-prefix -disable-nls -disable-intl -disable-po -with-
gnu-as -with-gnu-ld -disable-bootstrap -enable-threads -enable-rpath -enable-cld
 -enable-version-specific-runtime-libs -disable-checking -disable-win32-registry
 -enable-64-bit-bfd -with-build-sysroot -enable-languages=c,c++

Note that I don't really want -with-build-sysroot, not for compiling and linking the target libraries.
I was trying to point fixincludes at the correct files.
Not that fixincludes hasn't already run as part of the cross build.

Workaround could be, like:
  -with-build-sysroot=/usr/local/sparc-sun-solaris2.10/sys-root 
or
  -with-sysroot=/ -with-build-sysroot=/usr/local/sparc-sun-solaris2.10/sys-root 

I should never imho have to say -with-syroot=/.
However the documentation on -with-build-sysroot says it only
   makes a difference if -with-sysroot is also used.
I can figure it out though..


This seems like an age old minor but recurring software problem: 
When do you turn "special" values, such as "yes", into
"real" values, such as /usr/local/sparc-sun-solaris2.10/sys-root? 
The earlier you do it, the less code has to know about
the defaults, but the less code can act differently by differentiating
 the default vs. an explicit choice. More/less code
knowing about "special" and default values is both good/bad and bad/good.
 Sometimes as well you want to ferry
along special values through ignorant code. Like, in this example, gcc 
itself could translate "yes", perhaps.
Of course, then, the special value should reliably be in a different 
namespace, and "yes" strictly speaking is not
but reasonably speaking is, but throw in too many 
"reasonably speaking" and things can get messy fast..


In this particular case, there is probably not much 
value to delaying the substitution.


I am tempted to go further:
  cross and cross-to-native builds should validate "this stuff" early in configure, check that:  
     -with-sysroot or -with-build-sysroot or -with-headers is specified 
     or this is a merged tree with newlib or glibc (or djgpp runtime?) 
     In fact, one of them should be defaulted, unless it is a merged tree. 
     Or -inihibit-libc, if that is viable. Or skip building target libraries. 
    And if defaulted, check that the default path exists.  


 - Jay