[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Intend to create an -fPIC library package...

Am Mon, 20 Jul 2009 23:18:23 +0100
schrieb Roger Leigh <rleigh@codelibre.net>:

> On Mon, Jul 20, 2009 at 11:10:11PM +0200, Christian Hammers wrote:
> > Hello
> > 
> > In the Cc'ed bug report we were asked to created a libmysqld-pic
> > package that only contains libmysqld_pic.a which should be compiled
> > with -fPIC. As I'm no library expert I gladly follow the
> > recommendation of Policy §10.2 and ask for comments :) The reason
> > for creating this package was that libmysqld.a (the embeddable
> > MySQL server) should be included in other shared libraries, like
> > one from Modestas' Amarok package.
> 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

> 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:

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.



Reply to: