[debian-mysql] Bug#508406: Intend to create an -fPIC library package...

[Wouter Verhelst]

On Tue, Jul 21, 2009 at 12:40:17AM +0200, Christian Hammers wrote:
> Am Mon, 20 Jul 2009 23:18:23 +0100
> schrieb Roger Leigh <rleigh at codelibre.net>:
> > If other libraries are including this library, then why is libmysqld
> > not being provided as a properly-versioned shared object?
> 
> Upstream, in this case Monty himself, seems to explicitly want it to be
> a static library for performance reasons as I read from the discussion
> in: http://lists.mysql.com/internals/35950

In that case, and if we do indeed want to support this static library
interface, indirect users of libmysqld.a should link to it when they
compile their software. Shared libraries can in fact use symbols from
the 'main' program if they're compiled in like that -- except that, of
course, these shared libraries then depend on the assumption that the
static library does not change its ABI, and they have no way at all to
ensure that.

Adding a -fPIC static library obviously does not fix that problem; it
only makes the ABI management of those libraries that link in the -fPIC
static library infinitely more complex. Additionally, you introduce a
serious problem that may only be fixed by requiring that any library
which includes this -fPIC static library needs to use either symbol
versions or linker tricks to avoid multiple versions of the same symbol
from stumping on eachother's toes.

Whether we should recommend using static libraries is another matter
entirely; indeed performance does go down a teeny weeny bit when using
shared libraries, but the difference shouldn't be *that* large; if it
is, that probably means they're using a twisty maze of function calls,
all alike, that they probably shouldn't be doing. In my opinion, the
advantages gained by not doing shared libraries do not, by far, outweigh
the serious problems it introduces.

All this really sounds like a cop-out in that mysql upstream doesn't
want to deal with *real* performance optimizations. Not that I'd
expected something much different from MySQL. But I digress.

> > I am not convinced that compiling with -fPIC is appropriate here--it's
> > working around the fact that mysql isn't providing a properly
> > reusable shared library.  Linking an -fPIC static library (a) with a
> > shared library (b) will make the contents of (a) part of the exported
> > interface of (b) because it will by default be added to the dynamic
> > symbol table unless you take special action with linker scripts.
> > 
> > There are obvious issues with security updates if people are linking
> > against libmysqld.a, since all libraries linking against it will need
> > rebuilding if there's a security update.  If it's shared, that won't
> > normally be required.
> 
> At least RedHat and Gentoo already have experimented with building their
> own shared libraries from libmysqld.a:
> https://bugzilla.redhat.com/show_bug.cgi?id=149829
> https://bugs.gentoo.org/attachment.cgi?id=186606
> 
> So I try to get this working on Debian, too, and create a libmysqld0
> package with a shared library instead. Speaking of it, which soname
> version should I give it? 0.0.0? Or something like 0.5137.0 to somehow
> encode a version as I cannot promise that *I* know when
> they make API changes? .so.5.1.37 seems not to be a good idea in case
> MySQL somewhen starts to ship a libmysqld.so.5 themselves.

Don't just blindly use 'version of the server package' unless you really
really know what you're doing.

A SONAME should be bumped (i.e., the number after the .so. bit of the
filename and before the next dot increased) when the ABI changes
incompatibly. This may be when upstream changes the API incompatibly
(probably indeed only happens on an upstream major update), but there
are other cases where this might be the case (say, they add a variable
to a struct in a way so that the offsets change, or rely on users to use
malloc(sizeof(struct)) to allocate a new one, or a number of other
things) that might change at a minor (i.e., 5.1 -> 5.2) update. If that
happens, and you rely on the major upstream version number (5 in the
example) to change, then you've just created a shared object which
claims it is compatible with previous versions of itself but isn't, and
things will go kaboom all over the place.

Basically, I guess the only proper answer to your question is either
"audit upstream's ABI and bump the SONAME when required" or "slap
upstream in the face and demand they provide a proper shared library".
Except without the rudeness.

If you don't want to do either, then the only safe option you have is to
use libtool's -release option (or an equivalent of that which does not
use libtool). This, however, will mean that every time you do an
upstream update, even a minor one, you have a library transition on your
hands.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20090721/e18b4ada/attachment.pgp>