| Summary: | [RARE] cross-compiled static bins in /usr/obj/usr/src/i386 can cause Signal 4 during make installworld | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Keith Jones <keith> |
| Component: | bin | Assignee: | Marcel Moolenaar <marcel> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.1.1-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Keith Jones
2000-10-23 20:10:01 UTC
Responsible Changed From-To: freebsd-bugs->marcel Marcel, can you have a quick look at this and maybe add 'strip' to the copied programs in installworld. johan@FreeBSD.org wrote: > > Synopsis: [RARE] cross-compiled static bins in /usr/obj/usr/src/i386 can cause Signal 4 during make installworld > > Responsible-Changed-From-To: freebsd-bugs->marcel > Responsible-Changed-By: johan > Responsible-Changed-When: Wed Oct 25 11:29:58 PDT 2000 > Responsible-Changed-Why: > Marcel, can you have a quick look at this and maybe add 'strip' > to the copied programs in installworld. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=22256 There's no bug in the build process that I know of. The tools in /usr/obj that are specifically compiled to run on the build machine need to be linked against the libraries in /usr/lib. In this case the build machine is incompatible with the install machine, simply because the binaries and libraries were optimized for the build machine and by that unusable on the install machine. This is just as bad as building on Alpha and installing on IA-32. To make the build process a bit more resistant, we can force bootstrap, build and cross tools to be dynamicly linked instead of staticly linked. We should not add strip to installworld. Think about what would happen if we did a source upgrade on FreeBSD 2.2.5 and basicly install ELF over aout. We would be using an aout strip on ELF files... -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 State Changed From-To: open->closed Mixing libraries and binaries on different processor models within the same architecture is only supported if the libraries and binaries are not optimized for the specific processors. Future enhancements that rebuilt tools necessary for installation should allow this to certain extend. No plans currently exist to add such enhancements. This PR is closed to avoid confusion. The underlying idea is good, but the suggested fix is not. Alternatives exist to build on machine A and install on machine B, without running anything on machine B (ie set DESTDIR to a NFS mounted FS and run the install on machine A). If you think this PR is closed in error, let me know. |