Re: [Maria-developers] Latest libmysqld.so patch

Hi, Kristian! On Sep 30, Kristian Nielsen wrote:

Sergei Golubchik writes:

Thanks for review!

What I would now like to do is to discuss how to proceeed (where to push this basically).

On the one hand, the patch got rather more intrusive than I first wanted. The main issue is that now the mysys/mystrings/dbug code is linked dynamically by default, so these additional libmysys.so etc. libraries must be installed by packagers etc. for things to work; similarly extra -lmysys etc. is needed when using libmysqld.a.

I've fixed that - now libmysys/mystrings/dbug/vio are built statically again. And they're included in libmysqld. See two patches attached. But they're still built with -fPIC, otherwise libmysqld.so cannot take them. Unless --disable-shared was used, that is. I had to hack around automake - as it didn't want to install static convenience libraries. I hope it'll go away eventually - I don't see why we should install them at all.

On the other hand, I think this is generally an improvement, linking code dynamically rather than statically. Saves duplicating code and so on, and dynamic linking is where the world is moving (has moved, really).

I agree. But perhaps we'd better postpone this (making them dynamic) to 5.3. Besides, let's see what cmake based builds bring in 5.5.

And btw, I would like your help/hints on how to extend mysql_config to provide the right information for how to link.

Looks fine the way it is. We may want to document that for libtool enabled builds it's better to link with /usr/lib/mysql/libmysqld.la instead of `mysql_config --libmysqld-libs` because libtool knows all the dependencies and required linker options.

...

...

The plugin may optionally specify @plugin_static_if_no_embedded@ in CFLAGS/CXXFLAGS for the static target; this will avoid needlessly compiling with -fPIC if no libmysqld is being built.

With this patch, every source file for a plugin is compiled twice, once with -fPIC and once without.

However, if we are not building libmysqld, then the -fPIC versions will never be used.

In this case, @plugin_static_if_no_embedded@ will add -static to CFLAGS, avoiding the needless compilations with -fPIC. Otherwise it will be empty.

I'm not a big fan of providing @plugin_static_if_no_embedded@, @plugin_embedded_defs@ etc - and allowing plugins to use them. I'd rather prefer us to append the flags automatically, where needed. But let's not spend too much time on the perfect solution as we're moving to cmake based build system anyway.

...

I'd rather not build libmysql at all. Or, at least, not by default.

Right, let's add this on top of this patch once we find out where we want to push it?

ok

If we link libmysql_r with libmysys, it will also solve another issue I have (with conflicts between C and assembler versions of bmovXXX); I postponed this issue until we decided about linking libmysql_r with mysys etc (it seems you agree we should do this).

ok

...

...

-AC_DEFUN([MYSQL_PLUGIN_DEPENDS_ON_MYSQL_INTERNALS],[ - MYSQL_REQUIRE_PLUGIN([$1]) - m4_define([MYSQL_PLUGIN_DEPENDS_ON_MYSQL_INTERNALS_]AS_TR_CPP([$1]), [$2]) -])

I thought we agreed on IRC to keep it. Do you mean, you tried it and it didn't work?

Yes.

I tried quite hard to find a way to keep compatibility. But failed :-(

So in the end I gave up on this compatibility. Sad, however a small comfort is that

- This only hits plugins that say MYSQL_PLUGIN_DEPENDS_ON_MYSQL_INTERNALS(), which ideally they shouldn't anyway.

- This only hits static plugins, which in any case need an incompatible maria_declare_plugin() added in the source (though this can be handled with #ifdef; I wonder if there is m4/automake equivalent ifdef that could help here?)

okay. because 1. I don't want us to spend much time on this, as cmake based build system is coming (yup, I've said it for the third time :) 2. I only care that pbxt is affected, but pbxt is in our tree so we can apply our changes - not in the Paul's tree - and merge his changed periodically while keeping ours (bzr can handle that). I would prefer us to use vanilla pbxt, but as these are only changes in Makefile.am and plug.in, and taking 1 into account (didn't want to repeat it again :), I'm think it's fine to keep modified Makefile.am and plug.in in storage/pbxt in our tree. Assuming Paul doesn't mind. Regards, Sergei