Date: Wed, 07 Jul 1999 00:21:19 -0600 From: Warner Losh <imp@village.org> To: John Birrell <jb@cimlogic.com.au> Cc: current@FreeBSD.ORG Subject: Re: How to cross build Message-ID: <199907070621.AAA67977@harmony.village.org> In-Reply-To: Your message of "Wed, 07 Jul 1999 15:37:45 %2B1000." <199907070537.PAA49736@cimlogic.com.au> References: <199907070537.PAA49736@cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199907070537.PAA49736@cimlogic.com.au> John Birrell writes:
: 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.
That might be better, but it still has problems that I wasn't up to
solving just yet. You need more than just as, ld and cc1 to
successfully build the world. You will also need make, strip, install
and likely a few others as well that are slipping my mind. You will
also need different include files and different libraries (since the
machine link will be wrong in /usr/include, for example) if you are
building anything outside of the kernel.
: 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.
That's why I build a make with MACHINE_ARCH set to TARGET_ARCH so that
those assumptions in the tree work. It seemed easier to have to fix
all the places in the tree that weren't quite up to building cross
tools, and it appears to work in practice. Once that make is running,
it will report the correct MACHINE_ARCH for the target environment so
binutils and egcs work without major changes for the cross compilation
case (the minor changes I think are already in the tree).
: 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).
You'll need to do this for all binutils as well. I've also found that
I've needed to build make as well as libraries and include files to
have things work right. There may be others (install which uses the
other programs was a problem when I was working on the OpenBSD cross
build proceedure a while ago).
: I've been using
: /usr/libexec/${TARGET} where TARGET is a name quite close to that which
: binutils knows.
That would preclude us from porting to an architecture named "ftpd" or
any other program that is in /usr/libexec. I think you want to put a
/arch/ before the ${TARGET}, if you go down this path...
: Using the environment variable "TARGET" is a little
: problematic for me because it is easily confused (at least by my
: brain 8-) with .TARGET.
It never even dawned on me that this would be confused, to be honest.
OpenBSD, at least, uses TARGET and TARGET_ARCH, but has a different
way of setting them up than is in what I checked in.
Also, I think that your notion of running
make world INCLUDE_THESE_OTHER_TARGETS="mips m68k"
and then building the world (somehow) with these cross tools differs
from my world view. In my world view (which may be wrong, but was
what I arrived at after many false starts down other paths), one would
build the entire system with make buildworld. I do see the utility in
being able to do it other ways. But it would require more than just
programs to make it work.
I suspect that /usr/libexec/${TARGET} will prove to be too limited to
work in practice, especially for an entire buildworld (although I can
see how it could be made to work for kernel builds). I think we'd
need to have a /usr/cross/${TARGET}-${TARGET_ARCH}/ tree where the
libraries needed for linking, the include files that are specific to
each port, etc live. Then one could just set one's path to have
/usr/cross/${TARGET}-${TARGET_ARCH}/bin in your path and then make
from there anything you'd like. That would also allow us to have as
many different binaries as we need to build the world and we'd be
decoupled from any hacks to make binutils work. While this approach
would work well for kernel development, I don't see how it would work
well for development where libc is linked in.
Warner
P.S. /usr/cross is what OpenBSD uses, but I'm not married to that
name.
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?199907070621.AAA67977>