Re: installing libnbcompat as static library

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Wed, 18 Mar 2009 14:27:48 +0100
Roland Illig <roland.illig%gmx.de@localhost> wrote:

> Hi,
> 
> I wonder why each package that needs one of the "features" of
> libnbcompat has to configure and build libnbcompat. In my opinion, it
> would be easier to build it once with all the features and install it as
> $PREFIX/lib/libnbcompat.a.
> 
> I'm sure someone has considered this before, so what's the weak point of
> my suggestion?

Using libnbcompat installed as opposed to inplace makes pkgsrc bootstrap
more complicated, and since libnbcompat is used primarily by pkgtools
it makes sense for it to work that way.

(The rest of this mail is a general rant about libnbcompat, not about
your suggestion ...)

In the long run we need to move away from libnbcompat for "features",
because it exposes the package to all features (symbols) enabled on the
platform, not just those features that the package asked for. We may
end up needlessly replacing symbols provided by libc. One needs to
take care to avoid prototype conflicts with system headers. Also
there's the issue of features used by shared libraries and symbol
visibility.

I touched this subject briefly during my presentation at last year's
pkgsrccon and hope to have something that's not vaporware ready for this
year. Basically what I want to do is to install object and header files
to ${PREFIX}. During builds those can be used to assemble archives and
headers on the fly. That archive can be linked into binaries and
perhaps even shared objects by use of PIC. But as usual I'm sure the
devil is in the details ...

Cheers,
-Tobias