With a little more cross building experience...I'm still convinced there is a
problem here.
Canadian cross doesn't do the right thing in fixincludes.
There are remnants of a fix in the 4.3.1 configure.ac here:
# When building gcc with a cross-compiler, we need to adjust things so
# that the generator programs are still built with the native compiler.
# Also, we cannot run fixincludes or fix-header.
# These are the normal (build=host) settings:
CC_FOR_BUILD='$(CC)' AC_SUBST(CC_FOR_BUILD)
BUILD_CFLAGS='$(ALL_CFLAGS)' AC_SUBST(BUILD_CFLAGS)
STMP_FIXINC=stmp-fixinc AC_SUBST(STMP_FIXINC)
# Possibly disable fixproto, on a per-target basis.
case ${use_fixproto} in
no)
STMP_FIXPROTO=
;;
yes)
STMP_FIXPROTO=stmp-fixproto
;;
esac
AC_SUBST(STMP_FIXPROTO)
# And these apply if build != host, or we are generating coverage data
if test x$build != x$host || test "x$coverage_flags" != x
then
BUILD_CFLAGS='$(INTERNAL_CFLAGS) $(T_CFLAGS) $(CFLAGS_FOR_BUILD)'
if test "x$TARGET_SYSTEM_ROOT" = x; then
if test "x$STMP_FIXPROTO" != x; then
STMP_FIXPROTO=stmp-install-fixproto
fi
fi
fi
but it doesn't work. The above code is basically the same in trunk.
fix-includes still runs and uses the build headers instead of the target
headers.
-with-build-sysroot doesn't workaround because:
if test x$host != x$target
then
CROSS="-DCROSS_DIRECTORY_STRUCTURE"
ALL=all.cross
SYSTEM_HEADER_DIR=$build_system_header_dir
case "$host","$target" in
# Darwin crosses can use the host system's libraries and headers,
# because of the fat library support. Of course, it must be the
# same version of Darwin on both sides. Allow the user to
# just say --target=foo-darwin without a version number to mean
# "the version on this system".
*-*-darwin*,*-*-darwin*)
hostos=`echo $host | sed 's/.*-darwin/darwin/'`
targetos=`echo $target | sed 's/.*-darwin/darwin/'`
if test $hostos = $targetos -o $targetos = darwin ; then
CROSS=
SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)'
with_headers=yes
fi
;;
i?86-*-*,x86_64-*-* \
| powerpc*-*-*,powerpc64*-*-*)
CROSS="$CROSS -DNATIVE_CROSS" ;;
esac
elif test "x$TARGET_SYSTEM_ROOT" != x; then
SYSTEM_HEADER_DIR=$build_system_header_dir
fi
goes down the native path. Also same in trunk.
Oh, maybe I should do that thing where you make up a platform?
(I saw this in "Do-it-yourself Linux" similar to Linux-from-Scratch").
-host sparc-foo-solaris2.10 -target sparc-sun-solaris2.10
instead of:
-host sparc-sun-solaris2.10 -target sparc-sun-solaris2.10
?
That feels wrong..
Hm, am I supposed to run mkheaders after install? <<<
Ah, I guess so.
But still the above appears in need of repair.
And if user gives -with-build-sysroot, then fixincludes can be run
on the build machine in a Canadian cross.
I opened a bug, but it doesn't have all this info (yet).
- Jay
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: gcc@gcc.gnu.org
> Subject: RE: --sysroot=yes
> Date: Sat, 26 Jul 2008 08:12:14 +0000
>
>
> Joseph, Right, I read that in the docs and I understand.
> As well, this is probably unusual enough, that no default is needed?
>
> Do you agree, at least, that fixincludes has a bug here?
>
> For now I am working around by using -with-build-sysroot=/usr/local//sys-root.
> which is redundant but ok for compiling and linking, since the build=>target
> toolset in use
> was already configured with -with-sysroot. I expect it will fix fixincludes
> though.
> After all, fixincludes worked when building the buld=>target tools.
>
> The diff had at least one error, an extraneous ";;".
>
> I *really* think there's a bug here.
> But I agree the diff I sent is not necessarily the fix.
>
> 1) -with-build-sysroot should complain clearly and early if not given a
> parameter
> That is, if the parameter is "yes".
> (Autoconf should probably have a way to indicate a parameter is required, if
> it doesn't already.)
>
> 2) More importantly, fixincludes doesn't get the right headers in this
> scenario (Canadian cross?
> "crossing to native"? I think Canadian cross is not "there are three
> platforms", but that build != host,
> and there /might/ be three platforms. I think three platforms implies
> Canadian cross, but two can also?
> I understand the general picture, of build/host/target, just not what to call
> things "for short".)
>
> There is already a build=>target toolset that knows where to get files.
> Maybe fixincludes should be part of that?
> Well, actually, it is, but that isn't sufficient.
> It is the Makefile that is driving it that is "confused".
> A possible fix would be to "configure" fixinc.sh with defaults??
> No, that seems wrong. At least to include it in fixinc.sh directly.
> However an easy way to ferry this aspect of the build=>target configuration
> to the Canadian cross might be good.
> Some small file that gets "installed".
>
> I think -enable-bootstrap + -with-build-sysroot might also fix this, but I'd
> rather
> manually build/save/install the build=>target compiler.
> And I'm not sure, -enable-bootstrap for Canadian cross builds build=>target
> and build=>host compilers?
> (in my case target==host).
>
> You rather want gcc -print-sysroot I think.
> That should be a good fix.
>
> - Jay
>
>
>> Date: Fri, 25 Jul 2008 10:52:33 +0000
>> From: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED]
>> CC: gcc@gcc.gnu.org
>> Subject: RE: --sysroot=yes
>>
>> On Fri, 25 Jul 2008, Jay wrote:
>>
>>> It allows -with-build-sysroot to default like -with-sysroot.
>>
>> The purpose of --with-build-sysroot is if you have installed your sysroot
>> in a different location from the configured --prefix. For example, you
>> have configured with --prefix=/opt/somewhere, the final location the
>> toolchain will be configured for, but have installed the sysroot under
>> /scratch/somewhere, a staging location used in the build, and will be
>> installing with "make install prefix=/scratch/somewhere".
>>
>> There should be no need for or use of --with-build-sysroot except in
>> configurations like this.
>>
>> --
>> Joseph S. Myers
>> [EMAIL PROTECTED]
