Date: Thu, 30 Sep 1999 21:21:46 +0200 From: Marcel Moolenaar <marcel@scc.nl> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: current@FreeBSD.ORG Subject: Re: new sigset_t and upgrading: a proposal Message-ID: <37F3B84A.B07905AE@scc.nl> References: <199909301819.LAA23995@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Rodney W. Grimes" wrote: > > > 1. A compiler C running on machine 1 and capable of generating code > > for machine 2 (the compiler includes headers and libraries), > > 2. Source code compatible with compiler C, but also with machine 2. > > And also compatible with machine 1, that is the bugger right now > it seems. Have the sources been modified such that they are now > no longer portable :-(. I don't think that's necessary. If I have, say, MIPS assembler code, then I should be able to generate MIPS binaries on, say, Intel. MIPS assembler code is clearly not compatible with Intel. This is also true if I would make FreeBSD/Alpha on FreeBSD/i386. I'm speaking true cross-compilation here :-) > > The current build-tools target tries to solve that by creating a > > compiler C' by using cross-compilation. The result violates rule 1: > > Compiler C' is build for machine 2 and not for machine 1 and therefore > > should not be used on machine 1. This is where the discussion is all > > about. > > Then this is an error in the tools target, by design the tools are > suppose to be capable of running on machine 1, and producing code for > machine 2. But how do you know that you can build tools with sources for machine 2 to run on machine 1? You can't make i386 binaries with alpha assembler sources, for example. To put it differently, isn't this why we need to port software in the first place? > Only later when you do the ``make all'' over the tree do > you produce the compiler that runs on machine 2. Yes, you may end > up building gcc/egcs twice. Just like you may end up building make > twice. Yep. Unavoidable. > > So, as long as rule 2 is not violated, cross-compilation can be used to > > to build a -current system on -stable and thus also to handle upgrades. > > The problem is in the case where rule 2 is violated. What's needed is > > the ability to "port" the proper tools to machine 1. Well, the first > > thing that comes to mind is the ports collection... > > Why should ports have code that is any more portable than what is in > the src tree? It's not that ports have code that is more portable, ports have patches that are applied as part of the build to make it work on FreeBSD. Also, ports generally still run configure and friends to avoid compatibility problems. This have been staticized (sp?) in the source tree. > You should just be able to build egcs from the current > sources with the correct options and achive any results you could with > a port. But you'll be using -stable headers and libraries (at least, that should be case). This means that egcs, configured to build and run on -current may be improperly configured to build and run on -stable. > If you can't, then the src tree has been rendered non-portable. That may as well be the case. I can't give a more definite statement right now. > > 2. An easy, yet flexible way must be used to be able to tell whether > > ports must be installed or not. Simple rules like > > ".if $source < srcvers .and $target > trgvers .then install egcs" > > where $source = `sysctl kern.osreldate` and so on, may be sufficient. > > Irrelivant, just always build the correct set of tools. Trying to maintain > a list of the intertwinned dependicies can lead one to madness. Hmmm... Given the 2 cross-compilation prerequisites I gave, it follows that when the source machine has the proper tools for a cross-compilation, you don't need to build any tools as part of the build process itself. It could be advanteous to split a make world into a tools verification and installation phase, followed by the actual (cross)build. This can maybe also be used to handle bootstrapping problems on -current itself (compiling -current on a -current machine). It certainly minimizes unnecessary compilation and thus minimizes the time needed to do a make world. You may be right about going mad if you try to handle the interdependencies, though :-) -- 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 freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37F3B84A.B07905AE>