Date: Sun, 30 Jan 2000 01:06:02 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.org, committers@FreeBSD.org, Jeroen Ruigrok van der Werven <asmodai@bart.nl> Subject: RE: More world breakage Message-ID: <200001300606.BAA46567@server.baldwin.cx> In-Reply-To: <Pine.BSF.4.21.0001291346070.8191-100000@alphplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29-Jan-00 Bruce Evans wrote: > On Fri, 28 Jan 2000, John Baldwin wrote: > >>... >> Solution: >> >> We need statically built install tools just like we have build tools. >> I think we should use the newer versions (i.e. static versions of the >> ones we just built under /usr/obj during buildworld that are linked >> against the new libraries), rather than doing some fancy footwork to > > Using the newer version would be even more broken, since they may be > for another arch, or may just use new syscalls that don't exist in the > host kernel. 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. :( >> make the existing binaries work. We already do this with the build >> tools. By using the newer binaries we only have to maintain one >> interface in our Makefiles to the install tools: whatever their >> current interface is in /usr/src. > > The build-tools are carefully built so that work in the host environment. > Essentially the same thing needs to be done for installation tools. Agreed. > Bruce -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?200001300606.BAA46567>