[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Stop shipping static libraries for NetBSD
[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.
> 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
> This would basically eliminate the need for an ar(1) "zeroize"
> flag, 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.
>  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).
>  Because of  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 E. Metzger perry%piermont.com@localhost
> -- thorpej
Main Index |
Thread Index |