RE: --sysroot=yes

[Jay <jayk123 at hotmail dot com>]

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: jayk123@hotmail.com
> To: joseph@codesourcery.com
> 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: joseph@codesourcery.com
>> To: jayk123@hotmail.com
>> 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
>> joseph@codesourcery.com