Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Mar 2001 14:59:26 -0800 (PST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Marcel Moolenaar <marcel@cup.hp.com>
Cc:        qa@FreeBSD.org, marcel@FreeBSD.org, Larry Rosenman <ler@lerctr.org>
Subject:   Re: cputype=486
Message-ID:  <XFMail.010312145926.jhb@FreeBSD.org>
In-Reply-To: <3AAD3744.D434F14@cup.hp.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 12-Mar-01 Marcel Moolenaar wrote:
> Larry Rosenman wrote:
>> 
>> > In what stage?
>> 
>> look at ftp://ftp.lerctr.org/freebsd/makeworld-fw.out.gz for all the
>> gory details.
> 
> I did. It's a perfectly normal output from a buildworld. There's nothing
> wrong with it, nor is there anything wrong with a buildworld (per se).

Perhaps its not buildworld's fault then.  I was under the impression that it
did the installworld fine and the new strip that was built during
buildworld bombed out later.  It seems instead that strip bombs out during
installworld, which may be due to running the wrong strip binary during
installworld.

>> > This doesn't work. The object tree will contain binaries compiled for
>> > Pentium Pro processors and thus may contain instructions not present on
>> > i486. The binaries I'm talking about are those that are *explicitly*
>> > compiled to be run on the build machine. This includes the bootstrap,
>> > build and cross tools. These tools are also used during install and thus
>> > must be compatible with the machine you're installing on.
>> 
>> > In short: Do not not build on Pentium with -march=pentiumsomething and
>> > then later install on non-pentiums!
>> 
>> Excuse me, but the /usr/obj was WIPED OUT prior to the make buildworld.
> 
> This doesn't make the slightest difference, because the first thing that
> happens in a buildworld is a repopulation of /usr/obj (see below).
> 
>> So there was NO -march=pentiumpro objs left.
> 
> Your /usr/lib/libc.a has -march=pentiumpro code and consequently, any
> binaries that are staticly linked against it.

Hmm.  Ok, so why do we have the /tmp/install.XXX if we don't use them during
installworld?  This died on the 486 in installworld.  The installworld should
be using binaries from the machine being installed to (/tmp/install.XXXX)
right?  Maybe strip isn't in the install-tools list and should be?  In this
case, we are doing an installworld using the cross-tools (apparently, since
that is the only strip binary in usr/obj linked against the host machine's
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.

>> The binary that wound up in
>> /usr/obj/usr/src/i386/usr/bin/strip has ppro instructions in it.  This
>> seems wrong.

That isn't wrong, but that binary should not be used in installworld.

-- 

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.010312145926.jhb>