Subject: Re: cross compiling -cuurent on 1.4/alpha
To: NetBSD-current Discussion List <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 12/29/1999 11:37:24
Greg A. Woods wrote:
> [ On Sunday, December 26, 1999 at 13:28:01 (-0800), Bill Studenmund wrote: ]
> > Subject: Re: cross compiling -cuurent on 1.4/alpha
> > When DESTDIR is set, make build does not use /usr/include for the new
> > binaries(*). Which is cool as you can build a whole new world (including
> > tar balls) without touching your installed tree. You have to have
> > relatively recent tools (like make & friends), but they can (usually) be
> > built against the old headers & libraries.
> 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)
> 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.
> I think the FreeBSD process currently require superuser to effect this,
> but I think a relatively safe chdir() wrapper could be implemented to
> avoid this rather uncomfortable need to do builds as superuser, provided
> of course that some other facilities were also introduced, such as an
> "mtree" run as root at the right time fix up everything in $DESTDIR.
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...
ps: A safe chdir() wrapper is easy. A little more work goes into a safe
chroot() wrapper :-)