Re: ar "zero" flag

[christos%astron.com@localhost (Christos Zoulas)]

In article <5491AE6B-EA56-48F2-AEAF-1CE70FA71D9F%shagadelic.org@localhost>,
Jason Thorpe  <thorpej%shagadelic.org@localhost> 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).
>
>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.

I don't object to the elimination of static binaries (although it would
be nice to still support being able to build them; this is wishful thinking
because the code will bit-rot), but I think that eliminating _pic.a is
a bad idea because it makes it impossible for a developer who does not
want to re-build the system, to alter the system libraries. I have used
this feature numerous times on other system to repair problems.

christos