Bug 30276
| Summary: | CPUTYPE=486 built on a CPUTYPE=p3 WORLD breaks on INSTALLWORLD | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Larry Rosenman <ler> |
| Component: | i386 | Assignee: | Remko Lodder <remko> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
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 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 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: > > > > > > One problem with linking them shared is that they are not self-contained > > > 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 part > > > of installworld we install a brand new libc. Boom. Not only can we break > > > a parallel installworld, we can also break the install process at large > > > by having a libc that doesn't work anymore. > > > > > No booms here. We're requiring to install new kernel first. > > 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. > > > > 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. > > > > > This is not an approved way, and 4.0 can't be upgraded such a way. > > Correct; but it was were I was heading :-) > > > > Thirdly, people tend to build on their fastest machine and then do the > > > install on the machine they originally build for. By building the tools > > > staticly, you have a higher chance that it works. Especially if they > > > build on -stable and do the actual install on -current. > > > > > You'd have to be running with compat.4x libs enabled then. > > 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? > > > > Note that this > > > is currently not really supported, because we don't really deal with the > > > CPU optimization stuff > > > > > We build them with -DNO_CPU_CFLAGS nowadays. > > Ok, cool. I didn't know this. > > > > and we also don't rebuild tools if they can not > > > be used on the install machine (or even at all). > > > > > My proposal is an attempt to relax this restriction. The only restriction > > left (I should have said this earlier) is that libraries on the installing > > host should be feature-compatible with the corresponding libraries on the > > installing host. (Hmm, but this is often not the case, especially in the > > libc version bump case.) > > 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. > > 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... > > 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 :-) > 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, -- 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 test State Changed From-To: open->feedback 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 grab the pr State Changed From-To: feedback->closed 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! |
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. Fix: Update build system to NOT include host libc.a in any tools that will be executed on the target system. 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.