Date: Thu, 30 Sep 1999 14:00:08 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: marcel@scc.nl (Marcel Moolenaar) Cc: current@FreeBSD.ORG Subject: Re: new sigset_t and upgrading: a proposal Message-ID: <199909302100.OAA24301@gndrsh.dnsmgr.net> In-Reply-To: <37F3B84A.B07905AE@scc.nl> from Marcel Moolenaar at "Sep 30, 1999 09:21:46 pm"
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 :-) Your confusing yourself by mixing cross tools building with target building. You would never use the MIPS assembler source to build an i386 ``tool'' to build the i386 version of gcc that produces alpha binaires. It is a two stage process, say that slowly to yourself about 5 times... > > > 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? Because it is the FreeBSD source tree, and we control that aspect of it, if the above is a known. If it can't be done the sources are non-portable. > 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? But I can compile the gas assembler which is a portable assembler on anything to produce anything. The software is already ported. > > 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 keep going back to this stuff that won't work on FreeBSD. Now I can't see how you get there, but /usr/src is pretty much a sure win to run on FreeBSD if it _is_ FreeBSD. > > > 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). Exactly, thats what makes it the hosted cross compiler. The only thing we use it for is building the target binaries. Have you ever worked in cross platform development?? > This means that egcs, configured to build and run on -current > may be improperly configured to build and run on -stable. Then de statisize the configuration. > > > 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 :-) > I'm pretty sure that is the cause of the loss of a certain part of my life.... but since I can't remeber much about it I am not positive :-) -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net 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?199909302100.OAA24301>