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

[Jason Thorpe <thorpej%shagadelic.org@localhost>]

On Aug 6, 2008, at 3:33 PM, Greg A. Woods; Planix, Inc. wrote:

> > However, I'm perfectly OK with saying "if you do this, we don't  
> > jump through hoops to make sure stuff like PAM works".  Or threads.
>
> Well if the system only provides lame implementations of features  
> which result in them only supporting dynamic linking/loading, then  
> that's very short-sighted.

Sometimes it's just a matter of practicality.

> PAM, for example, can easily be implemented in such a way that a  
> static-only version can be built and used where all desired  
> mechanisms are statically linked into the system.  (Of course  
> choosing to use PAM in an environment where source code can be used  
> by _users_ to completely rebuild their systems is a poor idea in the  
> first place.)

Sure, it's "easy"... our PAM can already do it, but it sure is a pain,  
because programs that use PAM now have to know a priori which PAM  
mechanisms will be used so they can bring in all of the supporting  
libraries (e.g. the plethora of Kerberos libraries, etc.)

Of course, you could also make the argument that it's no longer PAM,  
because it's not exactly plug-able if you can't actually load a plug-in.

> The same applies to _every_ scenario where binary-only vendors have  
> tried to use dynamic/runtime loading of object code to support  
> additional flexibility in their distributions which might not  
> otherwise be possible without providing source code and the means  
> for _users_ to rebuild and update their systems _entirely_ from  
> source code only.  This is even true of some of the gargantuan UI  
> frameworks which currently require, for _very_ naive reasons,  
> dynamic runtime loading of object code.

As far as I can tell, you're making a religious argument, here.  Of  
course, I am in no way suggesting that NetBSD become a binary-only  
vendor.

> For example a simple patch in has shown that even the infamous  
> CITRUS support for locales can be fixed such that it trivially  
> supports static linking of all the desired runtime modules.
>
> Indeed I'm not aware yet of any real or valid reason to _require_  
> threaded programs to make use of a runtime dynamic link-loader  
> either.  PR #37454, for example, identifies an issue with the  
> current implementation, not a show-stopper that prevents use of  
> pthreads in static-only binaries.

Well, it's true that part of the issue with the current implementation  
is that pthreads is in a separate library.  Note, I have also  
advocated for pthreads to move directly into libc, and for all  
programs to behave as if they are "threaded".

> Much of the reasoning I've seen from you so far seems, at least from  
> my perspective, to be based solely on the requirements of binary- 
> only vendors.  You construe (in other posts) that "modern" systems  
> require in some way the use of runtime dynamic link/loading of code.

I'm not basing this on "the requirements of binary-only vendors".  And  
my assertion that modern systems "require in some way the use of  
runtime dynamic link/loading of code" is based on what I have   
observed of user expectations ... certainly not all users (since you  
are obviously so biased against the notion of dynamic extensibility).

>  That is simply _not_ true, except and unless you're considering  
> _only_ the requirements of binary-only vendors.  It may be a  
> _feature_ to give users of binary distributions the ability to  
> dynamically add new (and/or 3rd party) options to their systems  
> without requiring that they rebuild their entire systems from source  
> again, but such a feature is hardly a requirement of a "modern"  
> operating system.

Well, it's my opinion that an OS that does not provide such a feature  
is antiquated.  You're entitled to your opinion, and I'm entitled to  
mine.

> I certainly don't object to supporting mechanisms which binary-only  
> vendors might find useful to support additional runtime features in  
> their distributions, but I think it's critical to maintain full  
> support of static linking too.

We already don't have full support for static linking.  There are some  
things that don't work well/properly if you use static linking.  I  
don't think it's a good use of NetBSD's development resources to fix  
all of those issues and continue to maintain it going forward.

So, since we don't really support it fully anyway, and it would not be  
a good use of NetBSD development resources, I'm proposing to just get  
rid of it.  It would also simplify some aspects of maintaining /  
developing the NetBSD OS in the future.

> Indeed as a contributor and user of NetBSD I'm fully willing and  
> able to help as much as I can to maintain the ability of NetBSD to  
> make full use of all its modern features when it is built as a
> static-only binary distribution.

I can't really say that I've seen you contribute code in this area  
thus far...

-- thorpej