From ler@lerctr.org  Sun Sep  2 16:54:33 2001
Return-Path: <ler@lerctr.org>
Received: from lerbsd.lerctr.org (lerbsd.lerctr.org [207.158.72.45])
	by hub.freebsd.org (Postfix) with ESMTP id D2D7537B401
	for <FreeBSD-gnats-submit@freebsd.org>; Sun,  2 Sep 2001 16:54:32 -0700 (PDT)
Received: (from ler@localhost)
	by lerbsd.lerctr.org (8.11.5/8.11.5/20010512) id f82NsVS84599;
	Sun, 2 Sep 2001 18:54:31 -0500 (CDT)
	(envelope-from ler)
Message-Id: <200109022354.f82NsVS84599@lerbsd.lerctr.org>
Date: Sun, 2 Sep 2001 18:54:31 -0500 (CDT)
From: Larry Rosenman <ler@lerctr.org>
Reply-To: Larry Rosenman <ler@lerctr.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: CPUTYPE=486 built on a CPUTYPE=p3 WORLD breaks on INSTALLWORLD
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         30276
>Category:       i386
>Synopsis:       CPUTYPE=486 built on a CPUTYPE=p3 WORLD breaks on INSTALLWORLD
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    remko
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 02 17:00:02 PDT 2001
>Closed-Date:    Mon Sep 11 13:50:08 GMT 2006
>Last-Modified:  Mon Sep 11 13:50:08 GMT 2006
>Originator:     Larry Rosenman
>Release:        FreeBSD 4.4-RC i386
>Organization:
LERCTR Consulting, Garland, TX
>Environment:
System: FreeBSD lerbsd.lerctr.org 4.4-RC FreeBSD 4.4-RC #17: Sat Aug 18 17:22:20 CDT 2001 ler@lerbsd.lerctr.org:/usr/obj/usr/src/sys/LERBSD i386


>Description:
The cross-tools that are built use the *HOST* libc.a. Therefore certain tools
that are executed on the *TARGET* machine will possibly be linked with 
inappropriate libraries. 

The strip binary used during installworld is one of these, there may be others. 

I've had a discussion with Marcel Moolenaar and John Baldwin on the
freebsd-stable list both recently and around the 4.3-RELEASE cycle. 

This PR is to avoid the issue being lost. 

>How-To-Repeat:
	Build/Install world with /etc/make.conf having CPUTYPE=p3. 
        Update /etc/make.conf to change CPUTYPE=i486
        make buildworld
        NFS mount /usr/obj and /usr/src onto a 486
        make installworld on the 486
        watch strip die with SIGILL (signal #4) due to a P3 (cmova) instruction
        in the strip binary. 
>Fix:

Update build system to NOT include host libc.a in any tools that will be 
executed on the target system.  
>Release-Note:
>Audit-Trail:

From: Larry Rosenman <ler@lerctr.org>
To: freebsd-gnats-submit@freebsd.org
Cc: re@freebsd.org
Subject: i386/30276
Date: 30 Apr 2002 20:31:34 -0500

 Is anything going to happen with this PR ever? 
 -- 
 Larry Rosenman                     http://www.lerctr.org/~ler
 Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
 US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Larry Rosenman <ler@lerctr.org>
Cc: Bruce Evans <bde@FreeBSD.org>,
	Marcel Moolenaar <marcel@FreeBSD.org>
Subject: Re: i386/30276
Date: Thu, 15 Aug 2002 20:06:31 +0300

 On Thu, Aug 15, 2002 at 11:16:13AM -0500, Larry Rosenman wrote:
 > On Thu, 2002-08-15 at 10:59, Ruslan Ermilov wrote:
 [...]
 > > To be honest, I have no brilliant idea how to fix this.  One possible
 > > solution would be to split build- and install- tools, and always build
 > > install-tools on an installing machine, as part of installworld (this
 > > should probably be made a special case).  The most problematic thing
 > > here is strip(1) which is part of binutils; that would mean we would
 > > need to compile binutils twice.  I am not saying it's impossible, I
 > > am saying it is hard.  Many things that are used during build are
 > > also used during install, like for example, GNU texinfo suite:
 > > makeinfo(1) is used during build, install-info(1) -- during install.
 > > That also means we need to compile texinfo twice.
 > could we pre-strip those binaries that are installed somehow? 
 > 
 This wouldn't help too much -- strip(1) is only the largest problem
 here.  makewhatis(1) and install-info(1) are another culprits.
 
 > Could we modify the binutils build to use the built
 > /usr/obj/usr/lib/libc as a 2nd pass after they are built? 
 > 
 Idea!  We're currently building our bootstrap and cross-tools statically
 (see BMAKE in Makefile.inc1).  If we modify it to build them dynamically
 (note that on -CURRENT we also build them with NO_CPU_CFLAGS which helps
 as well), this would probably DTRT.  This will also require us to remove
 the sticky NOSHARED bits from some makefiles, by making them conditional
 on !BOOTSTRAPPING:
 
 	gnu/usr.bin/binutils/ar/Makefile
 	gnu/usr.bin/binutils/as/Makefile.inc0
 	gnu/usr.bin/binutils/gdb/Makefile (not affected)
 	gnu/usr.bin/binutils/ld/Makefile
 	gnu/usr.bin/binutils/ranlib/Makefile
 	gnu/usr.bin/cc/cc/Makefile
 	gnu/usr.bin/cc/cc1/Makefile
 	gnu/usr.bin/cc/cc1obj/Makefile
 	gnu/usr.bin/cc/cc1plus/Makefile
 	gnu/usr.bin/cc/cccp/Makefile
 	gnu/usr.bin/cc/cpp0/Makefile
 	gnu/usr.bin/ld/Makefile (legacy a.out support)
 	gnu/usr.bin/tar/Makefile
 	usr.bin/make/Makefile
 	usr.bin/objformat/Makefile
 
 gnu/usr.bin/binutils/gdb/Makefile is not affected because we build
 cross-tools with NO_GDB defined, and we don't descend here, but is
 probably worth fixing too, just for clarity.
 
 (bde@ Cc:ed as the NOSHARED lover.  marcel@ Cc:ed as the one who
 originally put NOSHARED here.)
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Marcel Moolenaar <marcel@xcllnt.net>
Cc: Larry Rosenman <ler@lerctr.org>, Bruce Evans <bde@FreeBSD.org>
Subject: Re: i386/30276
Date: Fri, 16 Aug 2002 13:29:39 +0300

 --d6Gm4EdcadzBjdND
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, Aug 15, 2002 at 01:39:27PM -0700, Marcel Moolenaar wrote:
 > On Thu, Aug 15, 2002 at 08:45:05PM +0300, Ruslan Ermilov wrote:
 > > >=20
 > > > One problem with linking them shared is that they are not self-contai=
 ned
 > > > anymore. What you get is this. Suppose install(1) is linked shared. It
 > > > runs fine, because it's built to run on the machine anyway. Now, as p=
 art
 > > > of installworld we install a brand new libc. Boom. Not only can we br=
 eak
 > > > a parallel installworld, we can also break the install process at lar=
 ge
 > > > by having a libc that doesn't work anymore.
 > > >=20
 > > No booms here.  We're requiring to install new kernel first.
 >=20
 > There doesn't necessarily have to be a kernel dependency. The FILE
 > related changes that were made early this year are a very good
 > example of how things can blow up even with an up-to-date kernel.
 >=20
 > > > Another reason for the -noshared is that it allows us a single-pass
 > > > upgrade path. With this I mean an upgrade path that builds world,
 > > > builds a kernel, installs a kernel, installs world, mergemaster-like
 > > > work and finally a reboot.
 > > >=20
 > > This is not an approved way, and 4.0 can't be upgraded such a way.
 >=20
 > Correct; but it was were I was heading :-)
 >=20
 > > > Thirdly, people tend to build on their fastest machine and then do the
 > > > install on the machine they originally build for. By building the too=
 ls
 > > > staticly, you have a higher chance that it works. Especially if they
 > > > build on -stable and do the actual install on -current.
 > > >=20
 > > You'd have to be running with compat.4x libs enabled then.
 >=20
 > Sure, but it would reduce the self-containedness of an installworld if
 > people would have to install compat4x first. Chances are they select
 > it as part of a world, but I don't think we install the compat libraries
 > before anything else, do we?
 >=20
 > > > Note that this
 > > > is currently not really supported, because we don't really deal with =
 the
 > > > CPU optimization stuff
 > > >=20
 > > We build them with -DNO_CPU_CFLAGS nowadays.
 >=20
 > Ok, cool. I didn't know this.
 >=20
 > > > and we also don't rebuild tools if they can not
 > > > be used on the install machine (or even at all).
 > > >=20
 > > My proposal is an attempt to relax this restriction.  The only restrict=
 ion
 > > left (I should have said this earlier) is that libraries on the install=
 ing
 > > host should be feature-compatible with the corresponding libraries on t=
 he
 > > installing host.  (Hmm, but this is often not the case, especially in t=
 he
 > > libc version bump case.)
 >=20
 > I think it's better to conditionally rebuild the tools. We could
 > easily avoid using yacc/bison, flex, gcc and other "build" tools
 > during installworld, so the set should be small and the tools
 > should be simple. The advantage of having a mechanism that
 > triggers the rebuild of certain tools is that you can probably
 > integrate the copying of native tools to a temp. dir as
 > we do now. The added advantage is that you can build instead
 > of copying.
 >=20
 > You can probably look at it as being a bootstrap phase for
 > installworld. It allows us to resolve runtime compatibility problems
 > (missing features or incompatible default behaviour) and other
 > warts...
 >=20
 > Anyway: this is mostly from the top of my head. I haven't actually
 > given this any real thought. It may as well be utter nonsense :-)
 >=20
 No, this is not nonsense.  That was actually my plan too, but I
 thought that this may be a better idea.  Now I see that it isn't.
 (See Bruce's email on the topic for more provoking things.)
 
 I planned to tidy the buildworld/installworld list of tools that
 we use anyway, and analyse some usage statistics, so I will probably
 stick this task on the top of it (because first I need to determine
 a full set of tools that we need during installworld).
 
 
 Cheers,
 --=20
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 
 --d6Gm4EdcadzBjdND
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.7 (FreeBSD)
 
 iD8DBQE9XNQTUkv4P6juNwoRAjnoAJ9OvtogUNohvh4ZxF+Uhe6Qz9Kl7gCbB9ZZ
 iiNfusFfQH2uoUaXTuxb9Nc=
 =u6lB
 -----END PGP SIGNATURE-----
 
 --d6Gm4EdcadzBjdND--

From: =?iso-2022-jp?B?GyRCMGFIZTJIGyhC?= <zy9h-eb@asahi-net.or.jp>
To: <freebsd-gnats-submit@FreeBSD.org>, <ler@lerctr.org>
Cc:  
Subject: Re: i386/30276: CPUTYPE=486 built on a CPUTYPE=p3 WORLD breaks on INSTALLWORLD
Date: Wed, 25 Jun 2003 00:47:48 +0900

 This is a multi-part message in MIME format.
 
 ------=_NextPart_000_0011_01C33AB3.6607A580
 Content-Type: text/plain;
 	charset="iso-2022-jp"
 Content-Transfer-Encoding: 7bit
 
 test
 
 ------=_NextPart_000_0011_01C33AB3.6607A580
 Content-Type: text/html;
 	charset="iso-2022-jp"
 Content-Transfer-Encoding: quoted-printable
 
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <HTML><HEAD>
 <META content=3D"text/html; charset=3Diso-2022-jp" =
 http-equiv=3DContent-Type>
 <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
 <STYLE></STYLE>
 </HEAD>
 <BODY bgColor=3D#ffffff>
 <DIV><FONT size=3D2>test</FONT></DIV></BODY></HTML>
 
 ------=_NextPart_000_0011_01C33AB3.6607A580--
 

From: =?iso-2022-jp?B?GyRCMGFIZTJIGyhC?= <zy9h-eb@asahi-net.or.jp>
To: <freebsd-gnats-submit@FreeBSD.org>, <ler@lerctr.org>
Cc:  
Subject: Re: i386/30276: CPUTYPE=486 built on a CPUTYPE=p3 WORLD breaks on INSTALLWORLD
Date: Wed, 25 Jun 2003 00:47:52 +0900

 This is a multi-part message in MIME format.
 
 ------=_NextPart_000_0016_01C33AB3.68CB3250
 Content-Type: text/plain;
 	charset="iso-2022-jp"
 Content-Transfer-Encoding: 7bit
 
 
 
 ------=_NextPart_000_0016_01C33AB3.68CB3250
 Content-Type: text/html;
 	charset="iso-2022-jp"
 Content-Transfer-Encoding: quoted-printable
 
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <HTML><HEAD>
 <META content=3D"text/html; charset=3Diso-2022-jp" =
 http-equiv=3DContent-Type>
 <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
 <STYLE></STYLE>
 </HEAD>
 <BODY bgColor=3D#ffffff>
 <DIV>&nbsp;</DIV></BODY></HTML>
 
 ------=_NextPart_000_0016_01C33AB3.68CB3250--
 
State-Changed-From-To: open->feedback 
State-Changed-By: remko 
State-Changed-When: Mon Sep 11 12:09:13 UTC 2006 
State-Changed-Why:  
Hello, 

We changed a lot in the crosscompiler stuff in the last period of 
time (the last years..) so can you tell us whether this still 
needs work ? 


Responsible-Changed-From-To: freebsd-i386->remko 
Responsible-Changed-By: remko 
Responsible-Changed-When: Mon Sep 11 12:09:13 UTC 2006 
Responsible-Changed-Why:  
grab the pr 

http://www.freebsd.org/cgi/query-pr.cgi?pr=30276 
State-Changed-From-To: feedback->closed 
State-Changed-By: remko 
State-Changed-When: Mon Sep 11 13:50:06 UTC 2006 
State-Changed-Why:  
The submitter no longer has the hardware to test this on (understandable 
after so long time), close the PR for that and if someone can give 
feedback, please feel free to contact me so that we can sort this out. 
Thanks Larry for the quick feedback! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=30276 
>Unformatted:
