From owner-cvs-all Wed Nov 17 3:42:31 1999 Delivered-To: cvs-all@freebsd.org Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id B647514C38; Wed, 17 Nov 1999 03:42:24 -0800 (PST) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11o3U2-0008PB-00; Wed, 17 Nov 1999 11:42:42 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id MAA06223; Wed, 17 Nov 1999 12:42:11 +0100 (CET) (envelope-from marcel@scc.nl) Message-ID: <38329493.82FFA536@scc.nl> Date: Wed, 17 Nov 1999 12:42:11 +0100 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Birrell Cc: Warner Losh , cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src Makefile.inc1 src/usr.bin/make Makefile 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> <19991117212631.A13376@freebsd1.cimlogic.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk John Birrell wrote: > > 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. sys.mk should not and need not be polluted. With the proper staging and/or phasing of the build process you can handle anything without trickery. > 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 This won't work. I'm not able to make the native, non-cross Alpha compiler in a cross-build, because MACHINE_ARCH=alpha in that case and __MA will be something other (say i386). In a cross-build you want to create the same world you do when you don't cross-build. This is not the case with your 'solution'. > The NOTOOLS setting does the trick (despite the fact that Bruce will > say I'm abusing it!). I agree with Bruce. Options like NOTOOLS and NOCLEAN are dangerous because you can only aim at your feet while using it. They are nothing more than the result of an inefficient build process that always ignores any previous work and always ignores the state of the host system... An optimal build process should do nothing when it is started right after the previous one is finished. > 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. Tools that fail to compile on older systems should be fixed, because they fail to be backward compatible. Using cross-compiling (cross-building would be more correct to call it) we are forced to cut loose and/or fix any references there may be to the includes and/or libraries of the host while cross-building. Such false references also break upgrading and can result in unexplanable behaviour of the resulting world. > 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. They should provide implementations of these functions so that they can be added to the mix of files in case the host doesn't have them. See egcs/gcc. > 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. Unnecessarily complex. Fix what is broken. Don't work-around it, unless a fix is not feasible. The build process is broken and fixing it would give us much more in return than a work-around in libc would do. > Building a kernel in as part of a make world is too complicated IMHO. kernel: cd ${.CURDIR}/sys/${MACHINE_ARCH}/conf; \ config -d ${KERNELBUILDDIR} ${KERNEL} cd ${KERNELBUILDDIR}; ${MAKE} depend; ${MAKE} all Piece of cake :-) -- 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