On Mon, Aug 27, 2007 at 08:30:29PM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > "David O'Brien" <[EMAIL PROTECTED]> writes: > : On Fri, Aug 24, 2007 at 09:36:15PM -0600, M. Warner Losh wrote: > : > In message: <[EMAIL PROTECTED]> > : > Daniel Eischen <[EMAIL PROTECTED]> writes: > : > : I guess the build system should be more tolerant of this, but > : > : there are bound to be problems regardless. I don't see why > : > : the install tools can't also either have their own set of > : > : libraries (utilizing LD_LIBRARY_PATH) or be built static. > : > > : > There's much resistance to building everything that the build system > : > might be used being build static. It adds too much time and > : > complexity to the build system, the opponents say. > : > : I've never heard an argument against building these bits static. > : What's the issue? > > I thought you were one of the folks making this argument when we last > changed the FILE structure and related hangers on. > > None of the binaries is built static by default, so we'd need to build It seems that toolchain is built static. Even binaries that go into the DESTDIR are static: % file /usr/bin/ld /usr/bin/ld: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, stripped
The same is true for as, cc, libexec/cc1, make. The list is definitely not exhaustive. > new versions of them static to make this scheme work. We cannot count > on them being static in the release that we're upgrading from. > However, if we do build new versions static, then they would depend on > the new version of the kernel rather than the current version of the > kernel. > > Warner
pgp7Ordq5TZI0.pgp
Description: PGP signature
