On 22-Nov-2008, at 5:08 PM, matthew green wrote:
thank you for continuing to ignore me when i say:
we are not removing static linking.
Well, such a thing has been proposed, and that proposal was taken seriously enough to need shooting down and in fact it seemed to require significant effort to shoot it down. To finish paraphrasing der Mouse, I'll agree with him that it is this fact which I find significant on its own. And, yes, though the proposal wasn't about removing static linking, it was clearly about removing self support for static linking of NetBSD itself, in its out-of-the-box source-code distribution.
That support was partly broken as early as NetBSD-1.6. In NetBSD-4 (and perhaps earlier), it is already impossible to do some useful things that are _assumed_ to be parts of the complete release when the whole system is static-linked. Indeed static linking the whole system without significant patches does not result in what a naive user could rightfully expect a true NetBSD release to be; eg. from the point of view of pkgsrc. You simply cannot build a significant set of packages from pkgsrc on a static-linked NetBSD despite the fact those packages were purported to be fully ported to NetBSD and supported by pkgsrc.
The worst part of this is that in at least one major part of the core system which currently requires dynamic linking the necessary patches to provide proper support for static linking have been available for a very long time already and yet they have not been incorporated into the official NetBSD sources.
I.e. there's a huge discrepancy between what you say and what's actually happening to the system as it is evolving.
I do have a successful static-linked variant of netbsd-4 which does come significantly closer to being a true NetBSD system in the sense that far more of pkgsrc will work as expected. It isn't complete though (not nearly as complete as my static-linked netbsd-1-6 variant) -- I've ignored a couple of other major components of NetBSD which currently rely on dynamic linking, and because in my environment I don't need them I don't even know much their omission might impact other outside components like pkgsrc.
The sad thing though is that it seems from the way static linked systems are currently broken that the developers responsible for breaking them aren't even cognizant of the problems they create. The fixes are often trivial (though sometimes requiring minor structural changes), but still they are ignored.
If those responsible for breaking some of the basic functionality in static linked binaries were to fix it and promote those fixes, get them pulled up to all supported releases, etc., then perhaps we might be more able to take your claim seriously. The code to fix CITRUS is already published and available and begging to be used, and I can confirm that it works very well. I'm not sure what's wrong with pthreads, but I'm told it doesn't work right in static-linked binaries and yet to me the kind of fix described sounded quite trivial for anyone experienced with the code involved. Then there's PAM and whatever is the "native" X.... As for dynamic code and the kernel, well there are other issues there, but the potential progressions are alarmingly similar.
--
Greg A. Woods; Planix, Inc.
<woods%planix.ca@localhost>
Attachment:
PGP.sig
Description: This is a digitally signed message part