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
