Re: fully supporting static linking in NetBSD (ar "zero" flag)

["David Brownlee" <abs%absd.org@localhost>]

From: Greg A. Woods; Planix, Inc. <woods%planix.ca@localhost>

> On 27-Nov-2008, at 5:47 AM, David Brownlee wrote:
> 
> 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.

Did anyone object to them last time, or did they just fall through the 
cracks?
If the latter would you be willing to check the patches against current and 
attach them to a PR? I'll see if anyone objects to getting them committed.

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

OK, then possibly we should return to this after the other issues are 
resolved...
 
> 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.

Presumably you have some staticly linked threaded apps running fine?

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

If they do not break anything else, then get them in.
 
> 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.
>
The goal is for you to stop having to do some of these changes time every 
timeyou update to a new version, plus to get them into the hands of other 
people who could find them useful. If no-one else would benefit from them 
then maybe they are best off just in your local tree, but hopefully someone 
will pipe up and offer to help...

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

Maybe you could pick some of the smaller changes and look at porting them 
forward to current. I'd certainly think I18N seems to be a good place to 
start, plus pkgsrc changes which are pretty much OS version neutral.