[ On Wednesday, December 29, 1999 at 11:37:24 (+1100), Simon Burge wrote: ]
> Subject: Re: cross compiling -cuurent on 1.4/alpha 
>
> Greg A. Woods wrote:
> >
> > So, why not go fully to the model FreeBSD uses and build all of the
> > development tools and install them in $DESTDIR, and then chdir($DESTDIR)

[[ oops: s/chdir/chroot/ above!  :-)  thanks for the correction! ]]

> > to do the full build (including re-building the build tools with just
> > themselves, but of course in a cross-build kind of way)?

> This assumes that the current kernel has all the system calls available
> that any new binaries might want to use - this may not be a valid
> assumption.  Think of a production box running a release version - it
> probably won't be able to use a new libc that would exist in the new
> build area.  Just booting a new kernel isn't always an option.

Oh, no, not at all!  That's why I say "in a cross-build kind of way."

Now that I think about it again though it's fairly obvious that the
chroot($DESTDIR) isn't really possible in a full cross-build
environment, at least not without mirroring the current system
libraries into the new build tree so that cross-compiler can bootstrap
itself up(down) to match that of the intended target system.

I guess a full cross-build wouldn't really have to do that either,
provided that the cross-tools on the build machine are current
(i.e. updated to be identical) with what will be the "native" tools in
the product build.  Even that wouldn't be necessary unless you wanted to
prove that the cross-compiler built identical binaries to the native
compiler (i.e. that a subsequent "make build" on the newly installed
target, with the same source tree, would generate identical binaries to
those the cross-compiler built on the original build machine).

Perhaps these two schemes can be supported simultaneously too, eg. with
something like "USENATIVECROSSCOMPILER" or "BOOTSTRAPTARGETCROSSCOMPILER"

In fact I think the boot-strap of the cross-build tools could still be
done without a chroot(), though perhaps not without jumbling up the
build environment so much that it doesn't work easily in the traditional
basic native rebuild way.  This might be good though.  If the entire
build system can be made smart enough that it's always capable of
building for any target, using any given set of tools, then I think we'd
be one step ahead....

If done right this makes it possible for any system capable of hosting
the cross-build tools to build a complete set of target products for any
given target architecture.  I'm not saying this would be easy to do, but
it could be done I think, and it may be good to do too.

> Except for the installation tools (which I think only get built with
> "make release"), NetBSD can to a "make build" as a normal user with
> $DESTDIR (with the right make(1) variables set) - just everything ends
> up as being owned by that user.  Sure, mtree(1) spits out warnings that
> it can't change the ownership of directories, but it works...

Hmm...  That's good to hear (I've not done a full build of -current for
quite some time now).  (I presume one of those settings is that of
BINOWN being set to one's own user-id for this to work.)

Has anyone discussed recently the various potential ways to record the
intended permissions of all of the installed files?  My favourite was
having install simply log all of its actions somewhere so they could be
converted to mtree format; which would also eliminate the need to
manually maintain src/distrib/sets/lists too if each install included a
"package" name too.  Indeed if these "install" logs were transformed on
the fly into pkg/PLIST and @mtree files then the "packagisation" of the
system would be relatively easy, and indeed this would mean any mortal
could build such system installation packages without having to be the
superuser.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>