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 <rle...@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
signature.asc
Description: Digital signature