From owner-freebsd-qa Mon Mar 12 22:46:47 2001 Delivered-To: freebsd-qa@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 7DA0A37B718; Mon, 12 Mar 2001 22:46:44 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f2D6jl164099; Mon, 12 Mar 2001 22:45:51 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3AAD68C0.E7E1DAD@cup.hp.com> Date: Mon, 12 Mar 2001 22:43:40 -0800 (PST) From: John Baldwin To: Marcel Moolenaar Subject: Re: cputype=486 Cc: Larry Rosenman , marcel@FreeBSD.org, qa@FreeBSD.org Sender: owner-freebsd-qa@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 -- 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