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.
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