Date: Thu, 26 Oct 2000 13:48:03 -0400 From: Marcel Moolenaar <marcel@cup.hp.com> To: Bruce Evans <bde@zeta.org.au> Cc: johan@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/22256: [RARE] cross-compiled static bins in /usr/obj/usr/src/i386can cause Signal 4 during make installworld Message-ID: <39F86E53.120FBD9A@cup.hp.com> References: <Pine.BSF.4.21.0010261703420.44146-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
>
> > To make the build process a bit more resistant, we can force bootstrap,
> ^^^^ less
^^^^ more
> > build and cross tools to be dynamicly linked instead of staticly linked.
^^^^^^^^^ staticly ^^^^^^^^
dynamicly
I noticed i switched two crucial words :-/
Building dynamicly does make it less resistant.
> I think adding the new strip to installworld would work, especially if
> it is statically linked. Similarly for all (?) the other binaries copied
> by installworld. We already depend on the new /bin/sh working as soon as
> it is installed, and if /bin/sh works then other non-binary utilities are
> likely to work. It is just considered safer to use the existing utilities.
Yes, it is safer to use the existing utilities. That is the reason why
our bootstrap phase is kept to a minimal. There are exceptions. In this
case I think strip is one of them. We can't depend on strip being able
to work on ELF. That would break upgrading from pre-3.0 aout systems. It
would also break our upgrading if for some unexpected reason we don't
use ELF anymore or there's an incompatibility in ELF. Since we already
built strip as part of the cross-tools, the strip in /usr/obj is capable
of running on the build-machine and therefore the safest version to use
(ie it is known to work with the object format of the target-machine).
Another reason why we should use strip from /usr/obj is that we don't
disallow cross-installations that way. For example; we can run "make
installworld MACHINE_ARCH=alpha" on a i386, and with DESTDIR set to some
mountpoint. Normally this probably isn't the preferred way to install
systems, but might be advantagous for installing onto removable media
when there's a single, fast build machine. Making this impossible by
design is more wrong than it being impossible by circumstances :-)
You're right about /bin/sh though. We should not install the new /bin/sh
until after we've installed everything. Doing this will probably be ugly
due to all the special casing. One way to reduce the pressure on /bin/sh
is by having make use the one saved by the install target. Backward
compatibility is an issue IIRC, because changing the shell in the
makefile was broken at some time (still is? was it ever?). Anyway, this
is still an open issue.
--
Marcel Moolenaar
mail: marcel@cup.hp.com / marcel@FreeBSD.org
tel: (408) 447-4222
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39F86E53.120FBD9A>