Date: Tue, 16 Nov 1999 19:18:35 +0100 From: Marcel Moolenaar <marcel@scc.nl> To: Warner Losh <imp@village.org> Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src Makefile.inc1 src/usr.bin/make Makefile Message-ID: <38319FFB.530FFCC6@scc.nl> References: <383189F7.67E89E8B@scc.nl> <38310A94.B1939A83@scc.nl> <199911151707.JAA03820@freefall.freebsd.org> <199911160533.WAA02391@harmony.village.org> <199911161544.IAA08642@harmony.village.org> <199911161714.KAA09479@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote:
> There are also makefiles in the
> kernel that use MACHINE, so both MACHINE and MACHINE_ARCH need to be
> defined in order for them to work correctly.
We currently have only 1 occurrence of MACHINE in /sys/boot/Makefile. I
found out (the hard way :-) that it is needed by the PC98 port. I made
it a special case (ie MACHINE_ARCH must be i386 before MACHINE is
tested). Maybe we can (mis)use MACHINE that way for other platforms as
well. I'm thinking about MIPS:
MACHINE_ARCH=mips,
MACHINE={seb|sel} /* or something like that */
That way we keep MACHINE_ARCH as clean as possible and use MACHINE for
architecture specific sub-targets...
> : I want to use TARGET_ARCH for building the cross-compiler:
[snip]
> : Currently MACHINE_ARCH is tested against `sysctl -n hw.machine_arch` and
> : if they differ then we're building a cross-compiler. This obviously
> : doesn't work if we are making the native MIPS compiler in a
> : cross-build...
>
> Yes. I put the TARGET and TARGET_ARCH in so that you know during the
> early part of the build process that you are on the host machine, but
> can switch that for later in the build process. You need to know what
> machine you are on early in the build process so you can build a
> compiler that runs on that machine, build a make, etc.
You don't actually need a variable for that. Everything that is build
with the standard compiler, includes and libraries will automaticly run
on the host. I think MACHINE_ARCH will mainly be used to select platform
specific (sub)directories or platform specific binaries/libraries.
> When cross
> compiling you can't use the host's libraries. However, there is a
> twist in this. Some programs, like fortune, builds programs that need
> to run in the host environment to create the programs that run in the
> target environment.
Correct. These little `gadgets' need to be build as tools, before the
actual cross-build is started. There's basicly one `gadget' that's
messing things up: genassym.c
We can't cross-build a kernel, because genassym.c needs to be build with
the targets includes and must be build with the cross-compiler for it to
properly have the offsets, but we need to run it on the host, during
kernel building :-(
> I don't think the above is going to work. gcc, and friends, have
> three levels here. host, target, and build. If you want to support
> three levels, maybe you need to go this route (eg if I'm building
> linux mips binaries to produce dec alpha osf1 code on my i386 freebsd
> box, host is i386-freebsd, target is dec-alpha-osf and build is
> linux-mips). With only two variables, you are going to only have host
> and target.
As I said, the host need not be specified, because it's not important.
gcc doesn't really care if I'm cross-building a cross-compiler. It just
needs to know on what platform the compiler is going to be run (ie
MACHINE_ARCH in my case) and what output it should generate (TARGET_ARCH
in my case).
--
Marcel Moolenaar mailto:marcel@scc.nl
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD project mailto:marcel@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38319FFB.530FFCC6>