On 27-Nov-2008, at 5:47 AM, David Brownlee wrote:
There are various aspects of support for static linking:
a) Basic static linking of base system, enough to boot multiuser
That's pretty easy, and it kind of goes along with the basic ability for anyone using a NetBSD system to static link any (suitable) program they might wish to build.
b) Features which currently only work on dynamic systems - i18n/PAM
The i18n stuff is easy -- patches have been posted and I've confirmed they work well on the netbsd-4 branch and I think they can easily be applied to -current.
PAM is a whole other story, and a much more contentious one. While a static-linked version of PAM could probably easily be hacked together by someone with some incentive to make it work, it really doesn't seem like the right answer. The BSD Auth stuff is agnostic about static linking and also solves a number of other issues with PAM, though a few very noisy folks seem to get their way in insisting that one contentious feature of PAM is actually a show-stopper despite the fact the actual requirement which drives it can be met in better ways with BSD Auth, and despite the fact that it seems an extremely small number of actual users would ever depend on this feature.
Apparently pthreads is also an issue. I don't have enough experience with it to say one way or another how big of an issue it might be. The only heavily thread-dependent pkgsrc applications I know for sure that I use are also ones that for various other unrelated reasons I have had to link dynamically anyway.
c) Building pkgsrc against a staticly linked system
Though I can't speak for even a significant portion of the vastness of pkgsrc these days, being that I only build about 500 packages or so for regular use, I can say that the only show-stopper I have run into recently is the i18n stuff, and that may only have been because I am also trying to static link as many packages as is reasonably possible too.
To also static-link as many packages as possible requires a few changes to the pkgsrc infrastructure, including some changes to libtool as well.
d) Building staticly linked tools
That's not too hard either, at least not for NetBSD native hosted builds.
We obviously have several people willing to commit to a),
and providing Greg and others can roll forward their patches
hopefully we can get some of the others also addressed.
The key is in minimising the cost in complication and effort
for keeping the various static linking support functional.
So... does anyone have references to PRs with reasonable sized
patches which apply to current? :)
Unfortunately given the state of my development tree, and especially given I effectively don't use any local version control (just CVS to compare against the official repository), I will probably need to find someone to work with who can help me create appropriate change sets.
Another complicating fact is I almost never work on -current, only on release branches. I suspect the same is true of many source code users of NetBSD, however most developers seem to expect that changes will always work directly on -current. I'm certainly willing to help someone re-integrate my changes to -current, but unfortunately I don't have the time or resources to do all my work twice myself.
I can make my work available in several different ways to anyone interested in integrating it to -current. Whatever works best for whomever can help!
--
Greg A. Woods; Planix, Inc.
<woods%planix.ca@localhost>
Attachment:
PGP.sig
Description: This is a digitally signed message part