From owner-freebsd-current Sun Jan 30 1: 0:43 2000 Delivered-To: freebsd-current@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id BFDDC14C96 for ; Sun, 30 Jan 2000 01:00:37 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (qmail 535 invoked from network); 30 Jan 2000 09:00:26 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 30 Jan 2000 09:00:26 -0000 Date: Sun, 30 Jan 2000 20:00:22 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: John Baldwin Cc: current@FreeBSD.org, committers@FreeBSD.org, Jeroen Ruigrok van der Werven Subject: RE: More world breakage In-Reply-To: <200001300606.BAA46567@server.baldwin.cx> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 30 Jan 2000, John Baldwin wrote: > On 29-Jan-00 Bruce Evans wrote: > One > question though, what architecture *should* the install-tools be? Whichever system they run on. This can be the host machine even for cross-compiling, if the target root is remote mounted. The main problem with this in -current is that some install rules put ${DESTDIR} in the installed files. perl is the main offender. > 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, It should be sufficient to copy at most a new install(1) from the host's obj dirs (except for a bare target machine, you need something like sysinstall to put a bit more than ssh there to begin with). Unfortunately, some bad install rules build things under ${DESTDIR} at install time and need much more than install(1) to do it. Guess what is the main offender. > 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. ... This problem is not limited to the install tools. After installing a new /bin/sh, you had better have a kernel that can run it. Problems can be reduced by linking new (target) tools static (if the target supports static linkage). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message