Date: Thu, 30 Sep 1999 23:55:30 +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: <37F3DC52.3B211424@scc.nl> References: <199909302100.OAA24301@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Rodney W. Grimes" wrote: > > > 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. Exactly. That's why I don't want a -stable make world to build the tools with -current sources to produce -current binaries. I want tools for -stable that can handle the task. If the tools from the source-tree are not appropriate, install newer versions from the ports collection. > It is a two stage process, say that slowly to yourself about 5 times... Spot on! Have make world first verify and install the proper tools without using anything from the source tree that you are using for the make world and after that make world with the toolset you have verified and/or installed in stage 1. > > > > 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. I think we should assume non-portability if we really want to make cross-compilation work. > > 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. In that case, we don't have to build gas as part of the make world. gas is capable of handling the cross-compilations we need... > > > 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. I'm not saying that it won't work, I'm just not making the assumption that it works. > > > 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?? Not enough. I am a compiler writer, though. > > 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 possible, yes. If the sources don't allow that, use ports. > > 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 :-) :-) -- 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?37F3DC52.3B211424>