Subject: Re: lightweight groff package?
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.ORG>
From: Greg A. Woods <>
List: tech-pkg
Date: 08/20/2003 18:53:59
[ On Wednesday, August 20, 2003 at 18:01:17 (-0400), Todd Vierling wrote: ]
> Subject: Re: lightweight groff package?
> On Wed, 20 Aug 2003, Greg A. Woods wrote:
> : > Right, but static libraries have runtime bloat too.
> :
> : Maybe.  It all depends on how many applications sharing the same library
> : might run at the same time.
> : It also depends on how often the application(s) in question are started.
> pkgsrc has no way to know either of these aspects of a given environment,
> so they are irrelevant in this context.

Well, actually I think pkgsrc maintainers could indeed make very good
guesses in many cases based on what kind of application is being
installed.  Many kinds of applications run for "long" periods of time
(e.g. at least many minutes, if not hours) and their start-up time is
indeed less important (though maybe you'd be surprised at just how much
faster the second xterm starts when it's static-linked :-).

>  (But note what I said about knobs
> that turn *off* default behaviors.)

Yes, of course.  I'd offer the knobs I've implemented for optional
static linking in pkgsrc, but they're kind of all-or-nothing at the

They are pretty simple though for the most part though -- just a few
patches to and the prefixing of all .so's in PLIST files with
a variable that will expand to "@comment" if ${LDSTATIC} contains
"-static".  Then the pkgsrc user can add "LDSTATIC=-static" to
/etc/mk.conf and build away.  Some packages do need extra CONFIGURE_ARGS
because some package authors are too enamoured with shared libraries for
their own good.  I may have tweaked libtool a bit too.  I have been able
to build some library packages with both shared and static libraries
thus making it possible to build the packages that use them either way.
However it seems libtool and autoconf get in the way more often than
they help, at least when it comes to managing 3rd-party libraries.

The biggest problem is of course with packages that may (optionally)
need to use dlopen() et all for so-called run-time plugins.  This
shouldn't be too hard to deal with in the package Makefile though and
thus one can still "forcibly" dynamic-link such packages.  I don't use
any such packages though so I haven't ironed out those little wrinkles

There's proably some in-between hack that could be done with that other
hack called libtool such that one could more selectively choose which
.so's are "found" by a package build (i.e. which libraries are forced to
be found only as .a's).  I didn't bother with trying this approach
though since my goal has been to build 100% static-linked systems and so
for me it's been much easier to just go all the way with "-static".

> NetBSD and its pkgsrc target machines where adding "sufficient RAM" is often
> not an option.  Hence pkgsrc uses shared objects rather broadly.

I don't think that's true in general for pkgsrc, and definitely not for
many of the packages where this shared library dependency is a problem
in the first place.  Few such machine that are capable of running these
things in the first place are so poorly endowed that static-linking just
the dependent libraries would make all that much of a difference in
terms of additional virtual memory requirements.  Even a measly 64MB
sparcstation can run a fully static-linked base system as a diskless
workstation, including with X11, without paging very often (i.e. not
noticably such that performance is adversely impacted), and 128MB system
almost never pages.

Generalizing that pkgsrc needs shared libraries is just as dangerous as
generalizing that it does not -- neither is ever entirely true overall.

Furthermore I'm betting that some folks would be willing to go to the
pain and expense of adding another stick of RAM to their systems just so
that they could selectively upgrade some of their packages without
having to rebuild their whole universe.

						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <>
Planix, Inc. <>          Secrets of the Weird <>