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:
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.
bye,
-christian-
Reply to: