Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Jan 2000 01:34:44 -0500
From:      Jim Bloom <bloom@acm.org>
To:        John Baldwin <jhb@FreeBSD.ORG>
Cc:        Bruce Evans <bde@zeta.org.au>, current@FreeBSD.ORG, committers@FreeBSD.ORG, Jeroen Ruigrok van der Werven <asmodai@bart.nl>
Subject:   Re: More world breakage
Message-ID:  <3893DB84.C20BF3DE@acm.org>
References:  <200001300606.BAA46567@server.baldwin.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
In the cross-build case, I would guess that the 'make installworld'
could be run on either machine.  It would depend upon which way the
mounts are done.  Is the host machine mounted on the target machine or
the other way around.  Some people strongly believe it should be one way
or the other.  Optimally, both cases should be handled correctly.

Jim Bloom
bloom@acm.org

John Baldwin wrote:
> 
> Hmm, ok.  I think my terminology may have been poor.  I meant that the
> new sources should have been used to build the tools, but using the
> existing machine headers/libraries to build the static binaries.  One
> question though, what architecture *should* the install-tools be?
> Normally, one would run installworld on the target machine and not
> necessarily the host machine.  For example, if I was cross-building an
> axp world on my x86 machine, then I would want to run 'make buildworld'
> on the x86, but would want to run 'make installworld' on the axp.  Thus,
> the build tools in that case need to be x86 binaries, but the install
> tools need to be axp binaries.  Of course, in that case you can't use
> the build machine's header files or libraries to build the install tools.
> Thus, you could use the headers/binaries in the source tree, except that
> you might then end up linking against a newer libc that needs a newer
> kernel to run.  The other choice is to build the install tools during
> installworld using the target machine's headers/libraries, but then
> installworld would no longer be a read-only operation. :(


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?3893DB84.C20BF3DE>