From owner-cvs-all Tue Nov 16 11:36: 2 1999 Delivered-To: cvs-all@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 435AB14A2D; Tue, 16 Nov 1999 11:35:55 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA03701; Tue, 16 Nov 1999 12:35:42 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA10311; Tue, 16 Nov 1999 12:35:46 -0700 (MST) Message-Id: <199911161935.MAA10311@harmony.village.org> To: Marcel Moolenaar Subject: Re: cvs commit: src Makefile.inc1 src/usr.bin/make Makefile Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org In-reply-to: Your message of "Tue, 16 Nov 1999 19:18:35 +0100." <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> Date: Tue, 16 Nov 1999 12:35:46 -0700 From: Warner Losh Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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