Date: Sun, 31 Mar 2002 20:21:33 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: cjclark@alum.mit.edu Cc: current@FreeBSD.ORG Subject: Re: Installing Cross Builds Message-ID: <20020401042133.GA66499@athlon.pn.xcllnt.net> In-Reply-To: <20020331193932.K99214@blossom.cjclark.org> References: <20020329131017.W97841@blossom.cjclark.org> <20020401015731.GA43494@athlon.pn.xcllnt.net> <20020331193932.K99214@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 31, 2002 at 07:39:33PM -0800, Crist J. Clark wrote:
> On Sun, Mar 31, 2002 at 05:57:31PM -0800, Marcel Moolenaar wrote:
> > On Fri, Mar 29, 2002 at 01:10:17PM -0800, Crist J. Clark wrote:
> > > After reviewing the world Makefiles, it sure looks like FreeBSD does
> > > not support 'installworld' of a cross build?
> >
> > Running installworld on machine X, when you did a cross-build for
> > machine X on machine Y is broken. All other cases should work,
> > AFACT.
> >
> > The brokenness is directly caused by inconsistent setting of OBJTREE.
> > This is indirectly caused make release, for make release expects the
> > object tree to be under /usr/obj and not /usr/obj/${TARGET_ARCH}.
>
> Well, the more direct reason for the breakage is caused by the fact
> that the PATH during install is,
>
> ${WORLDTMP}/usr/sbin:${WORLDTMP}/usr/bin:${WORLDTMP}/usr/games:${INSTALLTMP}
>
> Which is usually ${OBJTREE}${.CURDIR}/${MACHINE_ARCH}. But that
> directory doesn't exist. (Or is that what you are saying?)
It's not what I was saying, but you're right. I ran into this as well.
See below.
What I was saying is that a native build populates /usr/obj/<src-tree>,
but a cross build populates /usr/obj/<target-mach>/<src-tree>. It
would be more consistent to always populate /usr/obj/<target-mach>,
and fix make release.
> If you fix
> that, there is the same issue with ${OBJFORMAT_PATH}. Once you fix
> that, you have shared lib problems. (I've never quite figured out what
> ${INSTALLTMP} is even there for.)
The fix would be to populate WORLDTMP, or otherwise make sure those
binaries are in INSTALLTMP as well. The reason for INSTALLTMP is to
avoid pulling the rug from under your feet when you have a single
pass upgrade. We don't have that (yet?). We tell people to install
a new kernel, reboot and then run installworld. A single pass upgrade
would save enough programs and libraries to complete the upgrade and
then do a reboot. Another problem is parallelism. You may run into
the situation that you both install and run the same binary. This can
cause breakages.
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.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?20020401042133.GA66499>