> "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) [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
