Date: Tue, 16 Nov 1999 12:35:46 -0700 From: Warner Losh <imp@village.org> To: Marcel Moolenaar <marcel@scc.nl> Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src Makefile.inc1 src/usr.bin/make Makefile Message-ID: <199911161935.MAA10311@harmony.village.org> In-Reply-To: Your message of "Tue, 16 Nov 1999 19:18:35 %2B0100." <38319FFB.530FFCC6@scc.nl> References: <38319FFB.530FFCC6@scc.nl> <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
In message <38319FFB.530FFCC6@scc.nl> Marcel Moolenaar writes:
: 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'm not sure that I like this. MACHINE_ARCH is currently used by
pkg_* to make sure you don't install a intel binary on an alpha
machine, iirc (although it does appear this may be just a NetBSDism
from a quick grep I just did of the FreeBSD sources, or it could be
pure confusion on my part). The little endian vs big endian stuff
won't run on each other's processors (before the pedants chime in,
yes, in some R4000 chips one could do this, but that functionality has
been deleted and no one has ever produced an open source kernel that
got all the niggling cases right), so they really are different
architectures. In general, all binaries built for a given
MACHINE_ARCH will run on all machines in that MACHINE_ARCH (eg, I can
run binaries built for the i386 architecture on the pc98 port, save
kernel specific bits).
There is also a second vector that a mips port would need to consider,
which is the ability to use floating point or not. The WinCE machines
use software flowting point and need expensive kernel intervention if
you run a real FPU instruction. So you need a soft float
implementation and some way to tag the packages so that a smart
installer will install the right one. However, that's an issue for
down the road a ways.
There are also a bunch of flags to the compiler and binutils that need
to be given for one or the other. Traditionally, gcc and binutils
have encoded MACHINE_ARCH into the paths so that cross compilation
works. It would also break the "tradition" that the mips processors
have have defining MACHINE_ARCH to be mips for big endian machines and
mipsel for little endian mips machines. How did you propose making
the cross compilers do the right thing here?
So I'm not sure what is completely needed here.
: 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.
So long as it doesn't actually impact the building of native binaries
and the defines and whatnot work out correctly, I'm happy. I couldn't
find an easy way to thread this knot, but am very willing to let
others try and reap the rewards if they succeed.
: > 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 :-(
Yes. That's true. I had just assumed that we'd do something like the
NetBSD/OpenBSD people are doing and have a genassym.cf which is either
hand crafted or building on the target machine and then is used to
build the assembler headers.
: > 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).
I remain unconvinced, but if you can get all the gadget building to
happen in the host environment properly w/o this variable then you are
correct. I'll reserve judgement until I see it happening since I've
gone down this path and there are lots of pitfalls that I stumbled
into.
Actually, the other reason I had the make_cross_flags was so that I
could just run the make-arc binary and have it pick things up from the
right places for doing building outside of a make world. I routinely
would build both native and cross binaries from the same shell and
needed some way to differentiate which I wanted (since path wouldn't
do it). What I have works, but it is a kludge at best (since there is
still a bunch of stuff I have to setup before it works right). I look
forward to better things.
Warner
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?199911161935.MAA10311>