Stop shipping static libraries for NetBSD

[Bernd Ernesti <netbsd%lists.veego.de@localhost>]

[Starting as a new thread to get more attention to it, because I nearly deleted
it due too the fact that it was in the middle of another thread]

On Wed, Aug 06, 2008 at 02:25:20PM -0700, Jason Thorpe wrote:
> 
> On Aug 4, 2008, at 4:30 PM, Perry E. Metzger wrote:
> 
> Perry privately asked me to comment on this, and I've been thinking  
> about it for a bit now and have formulated a response :-)
> 
> As a short-term step, I don't object to the "zeroize" flag in  
> principle.  However, issues like this as well as issues with threads,  
> full-feature functionality, backwards-compatibility, etc. have led me  
> to conclude that it's time to deprecate static linking on our system[1].
> 
> I would like to propose that for NetBSD 6, we stop shipping .a, _p.a,  
> and _pic.a versions of system libraries, instead providing only  
> standard and profiling versions of the shared libraries (and maybe not  
> even separate profiling versions, if we can figure out a way to make  
> profiling work with the standard versions without any significant  
> performance impact in the non-profiled case).

I object to such a change, because that would make it impossible to build
static binaries.

> This would basically eliminate the need for an ar(1) "zeroize"  
> flag[2], because, if archives are not shipped, the metadata content of  
> those archives does not matter.  We of course would continue to  
> support archive libraries in the toolchain, and linking against them  
> for things like private libraries used by applications, or 3rd-party  
> libraries.  But linking against system libraries should all be dynamic.
> 
> [1] Obviously we would need to continue to support static linking on  
> platforms that don't have dynamic linking.  Since we no longer have  
> ns32k, that basically means mc68010 (sun2).
> 
> [2] Because of [1] and crunch, we'd probably need to continue to have  
> a "zeroize" flag in ar(1) for the same reasons we need it in the short  
> term.  However, going forward, I'd like to see us move away from  
> crunch to dynamically-linked install media.
> 
> >
> >The last big step to make builds fully reproduceable is to deal with
> >the fact that .a files contain date, user, group and permissions of
> >the original .o file that was packed into the .a
> >
> >Several people, including cgd, have independently suggested that a
> >flag to ar that said "zeroize the time, uid, etc., on packing" would
> >be appropriate. This would only be invoked for build.sh builds, and
> >appropriate logic would be put in to the makefiles or into make to
> >kludge around the fact that this would break the ability to update .a
> >files in situ in the build tree. (The kludge would be to remove the .a
> >file and rebuild it in the face of a .a file with zeroed timestamps,
> >which is not actually so bad.)
> >
> >If there are no objections in principle, I'll start working on it.
> >
> >Perry
> >-- 
> >Perry E. Metzger             perry%piermont.com@localhost
> 
> -- thorpej
>