From owner-cvs-all Wed Nov 17 2:24:53 1999 Delivered-To: cvs-all@freebsd.org Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 1E7D214C36; Wed, 17 Nov 1999 02:24:41 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id VAA14284; Wed, 17 Nov 1999 21:26:32 +1100 (EST) (envelope-from jb) Date: Wed, 17 Nov 1999 21:26:32 +1100 From: John Birrell To: Warner Losh Cc: Marcel Moolenaar , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 src/usr.bin/make Makefile Message-ID: <19991117212631.A13376@freebsd1.cimlogic.com.au> 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> <38319FFB.530FFCC6@scc.nl> <199911161935.MAA10311@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199911161935.MAA10311@harmony.village.org>; from Warner Losh on Tue, Nov 16, 1999 at 12:35:46PM -0700 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Tue, Nov 16, 1999 at 12:35:46PM -0700, Warner Losh wrote: > 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. The cross-build stuff that I've been working on allows MACHINE and MACHINE_ARCH to be overridden (from the built in host values in make) and all dependent things change accordingly. The "problem" of build tools being built and executed in place is solved by setting HOST_CC in sys.mk and using that instead of CC in the few places where this is required. My tests cross-build m68k on i386/alpha -- it's not complicated. I've sent a set of makefiles to David O'Brien which allow gcc/egcs to be built as host and cross-compilers. Most of the trickery needs to be in sys.mk (it gets poluted more!), not Makefile.inc1 to ensure that things like the bfd type set at all levels of the build. I find that make_cross_flags (or whatever) is not necessary in Makefile.inc1. A normal make world on the host machine should update all the tools that are needed for a cross-build. Then, for a cross-build, all you need to do in Makefile.inc1 is this: # Check if cross-compiling. __MA!=/sbin/sysctl -b hw.machine_arch __M!=/sbin/sysctl -b hw.machine .if ${__MA} != ${MACHINE_ARCH} || ${__M} != ${MACHINE} # Cross-compiling, so don't build tools. CROSS_COMPILING = 1 NOTOOLS = 1 .endif The NOTOOLS setting does the trick (despite the fact that Bruce will say I'm abusing it!). If the concept of "cross-compiling" is to be used as a solution to the upgrade problem, I'd like to see it solve the problem of old, incompatible tools before the commits are made. The problem is that some tools rely on things added to libc (like asprintf?) that don't exist on older systems, so attempting to build new tools against old headers/libraries fails. Prior to the signal changes, an upgrade to current from 2.2.5 was possible -- egcs may be a problem too, I haven't checked. Let's try not to burn people who aren't quite current/stable -- remember that what is current today will end up stable later on, so if we have a problem upgrading from 2.X/3.X to current, we should fix that before 4.0 goes out the door. I still believe that there should be compatibility in libc for the old signal interface while the running kernel doesn't support the new signal stuff. Building a kernel in as part of a make world is too complicated IMHO. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@cai.com john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message