Something LIKE the below diff SEEMS "better".
It allows -with-build-sysroot to default like -with-sysroot.
I'm not sure that's really a goal. Depending on the direction,
it is reasonable. Or very unnecessary. Like, either I'm inventing
a new use of -with-build-sysroot, and then default it, or avoid
this new use. Before this diff, -with-build-sysroot is totally
not meant for my scenario. The compiler and linker already handled
the scenario just fine. But fixincludes, I don't see how.
This change does actually affect the compiler/linker in a somewhat
unintentional undesired but ok way. It ends up with a redundant
--sysroot flag -- redundant with how the compiler was already configured.
It makes -without-build-sysroot and -without-sysroot act "as expected".
I'm not sure that's really a goal, but comments indicated so.
It should/might/I-have-to-test allow "cross to native" to use
-with-build-sysroot to "fix" fixincludes.
Fixing cross to native fixincludes is the goal.
Requiring the -with-build-sysroot switch, not really, but maybe reasonable.
However, while this seems largely reasonable, and lets me do what I want a bit
easier:
perfectly correct:
configure -disable-bootstrap -build i686-pc-cygwin -host i686-pc-cygwin
-target sparc-sun-solaris2.10 -with-sysroot
fairly easy and works and makes some sense:
configure -disable-bootstrap -build i686-pc-cygwin -host
sparc-sun-solaris2.10 -target sparc-sun-solaris2.10 -with-build-sysroot
what I really think is reasonably is merely:
configure -disable-bootstrap -build i686-pc-cygwin -host
sparc-sun-solaris2.10 -target sparc-sun-solaris2.10
The last step has other options:
- use the fixed includes from the previous
But where are they?
- sniff the right headers to fix from gcc -v ?
Noticing it was configured with -with-sysroot?
Seems like it'd work, but also feels like a new and not good precedent.
(Not that I'd know..)
- sniff the right headers to fix from gcc -M ?
Seems like it'd work.
Requires gcc in an earlier step, but I believe that is very reasonable.
or, furthermore, there is an apparent option configure -without-fixproto.
There is an apparent nearby no longer active one configure -without-fixincludes.
(I haven't looked at history.)
That would also maybe help -- gcc can cope ok without the fixed includes?
This seems a bit of a cop out, since the headers are available.
On one hand, what I'm doing seems like a very normal scenario, once
you get away from purely native builds. But maybe not? Maybe
cross builds that don't have either glibc or newlib are rare? Or
maybe "crossing to native" is rare? Cross builds usually about either
crossing to embedded that can't run tools, or crossing from a faster
to slower host and not wanting to build on the slower host??
(I'm still stuck for terminology. It doesn't seem "Canadian" because
host=target, but it does seem "Canadian" because build != host...?)
--- gcc.orig\configure.ac 2008-02-01 19:29:30.000000000 -0800
+++ gcc.mine\configure.ac 2008-07-25 01:35:59.453125000 -0700
@@ -1644,15 +1644,20 @@
# To find our prefix, in gcc_cv_tool_prefix.
ACX_TOOL_DIRS
-copy_dirs=
+SYSROOT_CFLAGS_FOR_TARGET=
AC_ARG_WITH([build-sysroot],
[ --with-build-sysroot=SYSROOT
use sysroot as the system root during the build],
- [if test x"$withval" != x ; then
- SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$withval"
- fi],
- [SYSROOT_CFLAGS_FOR_TARGET=])
+[
+ if test x"$with_build_sysroot" != x ; then
+ if test x"$with_build_sysroot" != xno ; then
+ if test x"$with_build_sysroot" = xyes ; then
+ with_build_sysroot='${exec_prefix}/${target_noncanonical}/sys-root'
+ fi
+ SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$with_build_sysroot"
+ fi
+ fi])
AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
AC_ARG_WITH([debug-prefix-map],
@@ -1667,6 +1672,8 @@
[DEBUG_PREFIX_CFLAGS_FOR_TARGET=])
AC_SUBST(DEBUG_PREFIX_CFLAGS_FOR_TARGET)
+copy_dirs=
+
# Handle --with-headers=XXX. If the value is not "yes", the contents of
# the named directory are copied to $(tooldir)/sys-include.
if test x"${with_headers}" != x && test x"${with_headers}" != xno ; then
--- gcc.orig\gcc\configure.ac 2008-05-21 01:54:15.000000000 -0700
+++ gcc.mine\gcc\configure.ac 2008-07-25 01:35:59.656250000 -0700
@@ -724,49 +724,82 @@
], [enable_shared=yes])
AC_SUBST(enable_shared)
-AC_ARG_WITH(build-sysroot,
- [ --with-build-sysroot=sysroot
- use sysroot as the system root during the build])
+
+#
+# Defaults for if neither -with-sysroot nor -with-build-sysroot are used.
+#
+TARGET_SYSTEM_ROOT=
+TARGET_SYSTEM_ROOT_DEFINE=
+CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
AC_ARG_WITH(sysroot,
[ --with-sysroot[=DIR] Search for usr/lib, usr/include, et al, within DIR.],
[
- case ${with_sysroot} in
- yes) TARGET_SYSTEM_ROOT='${exec_prefix}/${target_noncanonical}/sys-root' ;;
- *) TARGET_SYSTEM_ROOT=$with_sysroot ;;
- esac
-
- TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"$(TARGET_SYSTEM_ROOT)\"'
-
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
-
- if test "x$prefix" = xNONE; then
- test_prefix=/usr/local
- else
- test_prefix=$prefix
- fi
- if test "x$exec_prefix" = xNONE; then
- test_exec_prefix=$test_prefix
- else
- test_exec_prefix=$exec_prefix
- fi
- case ${TARGET_SYSTEM_ROOT} in
- "${test_prefix}"|"${test_prefix}/"*|\
- "${test_exec_prefix}"|"${test_exec_prefix}/"*|\
- '${prefix}'|'${prefix}/'*|\
- '${exec_prefix}'|'${exec_prefix}/'*)
- t="$TARGET_SYSTEM_ROOT_DEFINE -DTARGET_SYSTEM_ROOT_RELOCATABLE"
- TARGET_SYSTEM_ROOT_DEFINE="$t"
- ;;
- esac
-], [
- TARGET_SYSTEM_ROOT=
- TARGET_SYSTEM_ROOT_DEFINE=
- CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
+ if test x"$with_sysroot" != x ; then
+ if test x"$with_sysroot" != xno ; then
+ if test x"$with_sysroot" = xyes ; then
+ with_sysroot='${exec_prefix}/${target_noncanonical}/sys-root'
+ fi
+
TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"$(TARGET_SYSTEM_ROOT)\"'
+
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
+
+ if test "x$prefix" = xNONE; then
+ test_prefix=/usr/local
+ else
+ test_prefix=$prefix
+ fi
+ if test "x$exec_prefix" = xNONE; then
+ test_exec_prefix=$test_prefix
+ else
+ test_exec_prefix=$exec_prefix
+ fi
+ case ${TARGET_SYSTEM_ROOT} in
+ "${test_prefix}"|"${test_prefix}/"*|\
+ "${test_exec_prefix}"|"${test_exec_prefix}/"*|\
+ '${prefix}'|'${prefix}/'*|\
+ '${exec_prefix}'|'${exec_prefix}/'*)
+ TARGET_SYSTEM_ROOT_DEFINE="$TARGET_SYSTEM_ROOT_DEFINE
-DTARGET_SYSTEM_ROOT_RELOCATABLE"
+ ;;
+ esac
+ fi
+ fi
])
+
+
+#
+# build-sysroot is a copy/paste subset of sysroot
+# It is useful when crossing to native.
+# The resulting compiler is not sensitive to -with-build-sysroot.
+# Fixincludes on the build machine is. (the case I am fixing)
+# The bootstrap compiler is. (not tested)
+#
+# e.g.:
+# configure -disable-bootstrap -build=i686-pc-cygwin -host=i686-pc-cygwin
-target=sparc-sun-solaris2.10 -with-sysroot && make && make install
+# configure -disable-bootstrap -build=i686-pc-cygwin
-host=sparc-sun-solaris2.10 -target=sparc-sun-solaris2.10 -with-build-sysroot
&& make && make install DESTDIR=/usr/local/sparc-sun-solaris2.10/install
+#
+# It passes the same paths during "build", but not any defines that affect
"host".
+# That is, the same thing, but TARGET_SYSTEM_ROOT_DEFINE is not affected.
+#
+AC_ARG_WITH(build-sysroot,
+ [ --with-build-sysroot=sysroot
+ use sysroot as the system root during the build],
+[
+ if test x"$with_build_sysroot" != x ; then
+ if test x"$with_build_sysroot" != xno ; then
+ if test x"$with_build_sysroot" = xyes ; then
+ with_build_sysroot='${exec_prefix}/${target_noncanonical}/sys-root'
+ fi
+ TARGET_SYSTEM_ROOT=$with_build_sysroot ;;
+
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
+ fi
+ fi
+])
+
AC_SUBST(TARGET_SYSTEM_ROOT)
AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
AC_SUBST(CROSS_SYSTEM_HEADER_DIR)
+
# Build with intermodule optimisations
AC_ARG_ENABLE(intermodule,
[ --enable-intermodule build the compiler in one step],
Thoughts?
- Jay
----------------------------------------
> From: [EMAIL PROTECTED]
> To: [email protected]
> Subject: --sysroot=yes
> Date: Fri, 25 Jul 2008 05:43:21 +0000
>
>
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
