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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
