cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h

Kostik Belousov kostikbel at
Mon Aug 27 21:27:36 PDT 2007

On Mon, Aug 27, 2007 at 08:30:29PM -0600, M. Warner Losh wrote:
> In message: <20070828005654.GA50401 at>
>             "David O'Brien" <obrien at> writes:
> : On Fri, Aug 24, 2007 at 09:36:15PM -0600, M. Warner Losh wrote:
> : > In message: <Pine.GSO.4.64.0708242252520.15344 at>
> : >             Daniel Eischen <deischen at> 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

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the cvs-src mailing list