Date: Wed, 7 Jul 1999 15:37:45 +1000 (EST) From: John Birrell <jb@cimlogic.com.au> To: imp@village.org (Warner Losh) Cc: current@FreeBSD.ORG Subject: Re: How to cross build Message-ID: <199907070537.PAA49736@cimlogic.com.au> In-Reply-To: <199907070500.XAA67516@harmony.village.org> from Warner Losh at "Jul 6, 1999 11:00:48 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote:
>
> OK. Per many requests from the community, I've committed my cross
> compilation changes.
Thanks.
> To build you just say
> make buildworld TARGET=hpcmips TARGET_ARCH=mipsel
> or
> make buildworld TARGET=m68k TARGET_ARCH=m68k
> Right now you must specify both TARGET and TARGET_ARCH. You will want
> to do this with a clean /usr/obj. Please send comments to me.
>
> The one time I tried it, I was unable to build alpha binaries on i386
> due to bugs in the gnu tools. That was before egcs, however.
> Building i386 binaries on the alpha may work, but I don't have access
> to my Alpha lately to try.
binutils on i386 won't build 64-bit stuff due to bit shift code that
wants to shift more than 32 bits. At runtime the code strikes asserts
due to BFD64 not being defined at compile time. The sources hint at
using "long long" if using gcc, but it appears to require some hacking.
There is a Cygnus doc for configuring gcc 2.8.1 as a cross compiler which
says that building 32-bit code on a 64-bit machine doesn't quite
work. egcs might work though.
> This is a work in progress. Since I've been using this on MIPS, whose
> kernel includes aren't yet complete enough for make world, I don't
> know if it will work completely or not. The goal is to have a
> buildworld complete and then do an installworld in the native
> environment, or with a DESTDIR=xxxx to put the files in, say, an NFS
> mounted root partition.
>
> I did try to make this work with by redefining BINFORMAT, but I found
> too many problems with doing this because cc1 isn't dependent on
> BINFORMAT. It was easier to build explicit cross tools to make this
> happen.
I was aiming to build a set of cross tools as (an optional) part of the
i386 build like binutils. When building the cross-compiler, defining
CROSS_COMPILE and setting the execution path will avoid the native
compiler. Then in the mk files, set CC etc to be the cross compiler
based on the TARGET definition. The current install directory for the
extra gas versions should change to be the execution path that egcs is
configured for. I agree that BINFORMAT is inadequate. Since ld can be
shared between target formats, I guess a link to the host ld is all
that is required.
We can't rely on the setting of MACHINE_ARCH to twiddle the different
egcs build because that is a host setting, not a target one. We need
to set aside different directories and build the egcs code as many times
as the targets we want (like we do for gas). I've been using
/usr/libexec/${TARGET} where TARGET is a name quite close to that which
binutils knows. Using the environment variable "TARGET" is a little
problematic for me because it is easily confused (at least by my
brain 8-) with .TARGET.
> I've been using the cross binaries for a variety of purposes, so I
> have good confidence in at least that part of the commit.
--
John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907070537.PAA49736>