Date: Mon, 12 Mar 2001 22:43:40 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Marcel Moolenaar <marcel@cup.hp.com> Cc: Larry Rosenman <ler@lerctr.org>, marcel@FreeBSD.org, qa@FreeBSD.org Subject: Re: cputype=486 Message-ID: <XFMail.010312224340.jhb@FreeBSD.org> In-Reply-To: <3AAD68C0.E7E1DAD@cup.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13-Mar-01 Marcel Moolenaar wrote: > We also pick up the tools we previously built as part of the buildworld. > In this case, there's no point in saving strip if we use the one under > /usr/obj (see below for the flaw in the method). We can't use the one > installed on the system, because that one may not handle the object > format (think aout -> elf transition of example). Oh, ouch, that shoots a hole in number 1) below then. Argh. >> libc.a). This makes no sense. In the cross-arch case that would mean we >> would >> run an i386 binary to strip alpha binaries to try to strip the alpha >> binaries >> while running the installworld on the alpha. This would obviously not work. > > That's why the binaries are installed under /usr/obj/usr/src/i386. The > binaries are only valid on i386 machines. > > Hmmm... If the install is on an Alpha, we don't have a populated > /usr/obj/usr/src/alpha tree and consequently need to copy more tools > into /tmp/install.XXX ... I think we need to make sure the tools always > exist. This may mean that we need to build them during installworld as > well... Hmmm... Hmm, install-tools need to match the install machine, and I can see a few ways of achieving that but none of them seem perfect: 1) Copy said tools into /tmp/install.XXXX like we do now, but copy _all_ of them and just pull from that directory. This has the disadvantage that we have to be somewhat backwards compatible and can't use new tool options, etc. in installworld so that the old tools will work fine. 2) At the beginning of installworld, compile a new set of static install tools at the beginning on the install machine. This has several problems in that a) this would require mixing sources in usr/src with whatever headers and libraries are on the machine and thus aren't necessairly in sync leading to compile time or, even worse, run time errors, b) it would possibly not make installworld a read-only operation on usr/obj in a big way, and c) it would take a noticable amount of time. :) 3) We compile a separate set of static install tools during buildworld that are linked against the the libraries compiled during the normal world build that live in usr/obj/usr/src/lib/*. The downside here is again the extra time. Ugh, my head hurts. :-/ -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-qa" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010312224340.jhb>