Help wanted: Linking to libbind9 on Ubuntu Linux

[Robert Edmonds]

Ronald F. Guilmette wrote:
> In message <20180320205558.23ld7b2orcfkyg4o at mycre.ws>, 
> Robert Edmonds <edmonds at mycre.ws> wrote:
> 
> >Rick Dicaire wrote:
> >> For libbind9, https://packages.ubuntu.com/trusty/libbind9-90
> >
> >You would also need the ".so" symlink in order to link with -lbind9,
> >which is in this package:
> >https://packages.ubuntu.com/trusty/libbind-dev. This package is
> >confusingly named, though, it should probably have been named
> >libbind9-dev. It's unrelated to the original "libbind"
> >(https://www.isc.org/downloads/libbind/).
> 
> That all quite certainly *is* bloody confusing.
> 
> Firstly, I wish I understood the wisdom of the Linux/Ubuntu gods,
> specifically when they elected to place some files that *seem* like
> the library I was looking for into the /usr/lib/x86_64-linux-gnu
> directory but then also deciding to leave out the additional(.so)
> symlink necessary to actually use the bloody things (and putting
> that instead into some optional package that needs to be installed
> separately).

Hi, Ron:

It's typical on Linux distributions to split the runtime library and the
development headers plus .so symlink into separate packages. This allows
the co-installation of different versions of the same runtime library
with different ABI versions, for instance "libfoo1" (containing
libfoo.so.1) and "libfoo2" (containing libfoo.so.2). Binaries linked
against libfoo1 or libfoo2 continue working. Eventually you upgrade all
the old programs that link against libfoo1 to link against libfoo2 and
you can uninstall libfoo1.

This lets you have one version of the "development" package installed
(generally, the latest) so that newly compiled binaries link against the
newer ABI, while keeping older ABIs of the same runtime library around
so as to not break existing binaries. Since two separate packages can't
ship the exact same filesystem path, this is why the .so symlink is in
the development package rather than in the runtime library package.

This is the oversimplified explanation for a typical package, and I
probably got some things wrong. If you're starting your own Linux
distribution you might want to check out these documents:

https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

https://www.akkadia.org/drepper/dsohowto.pdf

> Second, I wish I undrstood your comment that the the files that appear
> on my Ubuntu system and whose names begin with "libbind9" are "unrelated"
> to the "real thing" (ISC) library of the same name.

What I meant is that on Debian/Ubuntu systems, the "libbind-dev" package
contains the libbind*9*.so symlink (as well as some other .so symlinks).
The "9" is not an ABI number, it's part of the basename of the library,
so the package probably should originally been called "libbind9-dev".

This caused a minor annoyance when I packaged the actual libbind (the
standalone BIND 4/8 resolver that briefly existed:
https://ftp.isc.org/isc/libbind/6.0/) for Debian. Its -dev package
should have been named, by convention, "libbind-dev", since it shipped a
libbind.so symlink, but the "libbind-dev" package name was already
taken.

> I suppose that when I grow up I will understand all these things, but
> right now it is all bloody preplexing.
> 
> Not that any of this is in any way ISC's fault.  It looks to me as if
> the Linux people just may have some funny ideas about how to organize
> things.
> 
> >However, note that there's also a proposal to get rid of the public
> >BIND9 libraries and turn these into private APIs:
> >
> >https://gitlab.isc.org/isc-projects/bind9/issues/88
> 
> Oh vey!  So, I guess that, going forward, it will be a Good Thing if I
> try to make sure that my code will plug-and-play alright with the
> Linux libresolv, as there may be no other choice on that platform in
> the future... unless I really want to code up the routines I want myself
> from scratch.  (I certainly could do that, if necessary.  I'm not even
> using that much out of the library, as I do my own packet parsing and
> compression.  I'd just prefer not to.)

If you are parsing packets and chasing compression pointers, there are
other DNS resolver libraries commonly available in packaged format on
Linux systems that are probably more suitable than libresolv (for
instance, https://www.nlnetlabs.nl/projects/ldns/), but I hesitate to
make such a recommendation on an ISC mailing list :-)

-- 
Robert Edmonds