Hi, Vladislav! On Sep 23, Vladislav Vaintroub wrote:
-----Original Message----- From: Steve Ellcey [mailto:sje@cup.hp.com] Sent: Freitag, 23. September 2011 00:37 To: Vladislav Vaintroub Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Shared plugin library build question
I think compiling with PIC should only be needed if libsqlservices code is intended to be linked into a shared library and I am not sure if that is the case or not.
It is intended.
Here is the error message that libtool gives me during the build:
*** Warning: linker path does not have real file for library -lmysqlservices. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libmysqlservices and none of the candidates passed a file format test *** using a file magic. Last file checked: /wsp/sje/mariadb/isvn/mariadb- project/5.3.1.beta/obj_gcc/libservices/libmysqlservices.a
Ok, libtool is being smart here..
What happens if you change the definition of ha_federated_la_LDFLAGS in federated/Makefile.am to ha_federated_la_LDFLAGS = -module -rpath $(pkgplugindir) $(top_builddir)/libservices/libmysqlservices.a (Disclaimer, I have not tried it myself, the intention is to get rid of -l<libname> in favor of full path to the static library. This I think has more chances to be successful)
I've just tried. It produces *** Warning: Linking the shared library ha_example.la against the *** static library ../../libservices/libmysqlservices.a is not portable! but seems to work nevertheless. The main question was - whether dependency tracking works, that is, only those services that are really used should get into the final binary, not the complete libmysqlservices.a. And it does work (verified with nm). Regards, Sergei