From owner-freebsd-qa Mon Mar 12 13:36:39 2001 Delivered-To: freebsd-qa@freebsd.org Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11]) by hub.freebsd.org (Postfix) with ESMTP id 6E9E037B71A; Mon, 12 Mar 2001 13:36:34 -0800 (PST) (envelope-from ler@lerctr.org) Received: from ler-freebie.iadfw.net (ler-freebie.iadfw.net [206.66.13.221]) by lerami.lerctr.org (8.11.3/8.11.3/20010112/$Revision: 1.13 $) with SMTP id f2CLRRI03534; Mon, 12 Mar 2001 15:27:28 -0600 (CST) (envelope-from ler@lerctr.org) From: Larry Rosenman Date: Mon, 12 Mar 2001 21:27:27 GMT Message-ID: <20010312.21272700@ler-freebie.iadfw.net> Subject: Re: cputype=486 To: Marcel Moolenaar Cc: John Baldwin , Larry Rosenman , qa@FreeBSD.org, marcel@FreeBSD.org In-Reply-To: <3AAD394D.49597B93@cup.hp.com> References: <3AAD394D.49597B93@cup.hp.com> X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2; Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-qa@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 3/12/01, 3:02:05 PM, Marcel Moolenaar wrote=20 regarding Re: cputype=3D486: > John Baldwin wrote: > > > > On 12-Mar-01 Marcel Moolenaar wrote: > > > John Baldwin wrote: > > >> > > >> It looks like strip is linked against /usr/lib/libc.a. > > >> > > >> Marcel, > > >> > > >> It looks like there may be a bug in buildworld. It seems that st= atic > > >> binaries > > >> are being linked against /usr/lib/libc.a rather than > > >> /usr/obj/usr/src/i386/lib/libc/libc.a. > > > > > > In what stage? > > > > The final strip binary that will live in /usr/bin/strip on the targe= t=20 machine. > Which is the one in: > /usr/obj/usr/src/gnu/usr.bin/binutils/strip > and not the one in: > /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/binutils/strip > Are we still talking about the same strip(1)? > > > In short: Do not not build on Pentium with -march=3Dpentiumsomethi= ng and > > > then later install on non-pentiums! > > > > Uh, how can cross-builds _possibly_ work then???? If I do a i386 ->= alpha > > cross build does the alpha /usr/bin/strip get linked against the i38= 6 > > /usr/lib/libc.a on the host machine?? > Of course not. The one that's being built as part of the cross-tools i= s > however. > > Or is libc treated magically by the > > compiler? > No. > > For that matter, what if a static binary uses a new function added > > to libc, how in the world will that link if we all our binaries agai= nst=20 the > > old libc during the world? That's just wrong. > No, that's not wrong. Just think about it for a moment. You need to > build cross tools first. Those must run on the build machine. You > therefore build those exactly as you build anything else: you use the > libraries on that machine. After you have built your cross tools, you > can start building non-native libraries, against which you link the > final non-native binaries. So what you are saying is cross build HOSTS have to suffer in performanc= e=20 while they are being used as the HOST? Why should this be?=20 In this case the make buildworld was done on a HOST that was built=20 -march=3Dpentiumpro, the make flags for the new build were with NO -marc= h=20 (or with -m486), and then the make installworld dies with the SIGNAL 4, = on a PPRO instruction in whatever strip binary is run from install. Thi= s=20 seems VERY wrong if we are going to support cross-environment builds AT = ALL. So, we can't use CPUTYPE?=20 This seems like a net lossage.=20 LER To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-qa" in the body of the message