Unit tests of internal functions
jhutz at cmu.edu
Tue Dec 29 17:43:39 EST 2009
--On Monday, December 28, 2009 04:51:53 PM -0800 Russ Allbery
<rra at stanford.edu> wrote:
> FWIW, I'm moving all of my packages to Automake and Libtool, and while
> that approach is not without problems, I think it's the right direction to
> go. It means that there's at least some hope that other people have
> already run into whatever weird build problem you have and have written
> recipes to deal with, or even taught Automake and Libtool about it
> directly. Upstream on both projects is fairly responsive.
> Also, there's the general advantage that a lot more people out there know
> Automake and Libtool than know the build system of any single project,
> which means it's more likely that you can find people who can patch your
> build system.
However, as someone who builds and deploys a lot of software, my preference
is that _every_ package that builds shared libraries uses libtool.
Why? Because it turns out that some of the most annoying problems can be
made to go away with a relatively minor patch to libtool, at the expense of
making it not work at all on a couple of platforms I happen not to care
about. We locally maintain patched libtool, and simply relibtoolize each
package as it comes in. We also maintain local patches that help us adjust
the soname of every shared library to depend on the versions of its
dependencies. So, for example, a (Heimdal) libkrb5.so built against
OpenSSL 0.9.8 will have a different soname from the same version of
libkrb5.so built against OpenSSL 0.9.7. This turns out to be really
important when you have complex applications with multiple direct and
indirect dependencies on the same library.
Anyway, the point is, if a package uses libtool, I can get all the special
behavior I need by relibtoolizing. If it doesn't, I get to figure out how
its super-special shared-library build system works.
So, libtool sucks, but please, use it anyway.
More information about the krbdev