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

["Greg A. Woods; Planix, Inc." <woods%planix.ca@localhost>]

On 6-Aug-08, at 5:36 PM, Jason Thorpe wrote:
> If you want to go through the pain and hassle of all that crap  
> yourself, feel free to build the OS from source (and turn on  
> whatever switch we use to enable building / installing the archive  
> libraries).  If you want to link the entire system statically, you  
> have to do that anyway since by default the entire system is linked  
> dynamically.  As I said in my previous message, we have to continue  
> to support the mechanism for sun2.

I hope you don't mean that in any way sarcastically.  Sadly it seems  
to me from your tone that you do.

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

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

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.

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.


> > What a horridly binary vendor centric viewpoint you have these days  
> > Jason.
>
> Huh?  In what way?

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

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.

As such I also don't object to NetBSD.org, when acting as a vendor of  
a binary system distribution, to choose to use dynamic linking and  
shared libraries to as great an extent as is desired.

However I, as a contributor and user, would strongly object to  
NetBSD.org, when acting as a vendor of source code, if it were to  
choose to subvert and obfuscate and discount the relevance and  
benefits of building the NetBSD source code base in a static-only  
manner.

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.

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