MySQL Bugs: #8796: libmysqlclient.a should be compiled with -fPIC on x86

Bug #8796	libmysqlclient.a should be compiled with -fPIC on x86_64 platforms
Submitted:	24 Feb 2005 22:30	Modified:	23 May 2007 20:50
Reporter:	Ryan Heule	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Packaging	Severity:	S2 (Serious)
Version:	5.0.38, 5.0.34, 4.1.9 standard	OS:	Linux (Fedora Core 2)
Assigned to:		CPU Architecture:	Any

Description:
I am trying to compile the DBD::mysql perl module on an x86_64 platform and I get the following errors:

[some stuff cut out here]

rm -f blib/arch/auto/DBD/mysql/mysql.so
LD_RUN_PATH="/usr/lib" /usr/bin/perl myld cc  -shared -L/usr/local/lib dbdimp.o mysql.o  -o blib/arch/auto/DBD/mysql/mysql.so     \
   -L/usr/local/mysql/lib -lmysqlclient -lcrypt -lnsl -lm -lz   \
   
/usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
/usr/local/mysql/lib/libmysqlclient.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
chmod 755 blib/arch/auto/DBD/mysql/mysql.so
chmod: cannot access `blib/arch/auto/DBD/mysql/mysql.so': No such file or directory
make: *** [blib/arch/auto/DBD/mysql/mysql.so] Error 1

After a couple of days of digging around, this is what I've found:
1.  If only static libraries are provided, they should be compiled with -fPIC on the x86_64 platform (this is different from regular x86).  This allows other people to create their own shared libraries from your static libraries by linking against them, which is what DBD::mysql is trying to do with libmysqlclient.a.  I found this information at http://www.x86-64.org/lists/discuss/msg05760.html -- even though it is not about mysql, it is about this specific linker error.
2.  This same bug was filed under Mysql Bug #4670, which was closed with a work around listed (complile a dynamic libmysqlclient library and link against that instead).  I believe that it is still a bug, however, because only a workaround is listed--the actual fix would be to link all static libraries for x86_64 platforms with -fPIC.

I will attempt to compile my own libmysqlclient with -fPIC, but it would save a lot of headaches for other people if they came compiled that way with the binary distributions.

How to repeat:
Try to compile DBD::mysql on an x86_64 platform with static mysql libraries (no dynamic libraries were provided with the binary distributions)

Suggested fix:
Begin compiling static libraries (specifically libmysqlclient.a) with -fPIC on the x86_64 platform or provide dynamic libraries in addition to the static libraries.

related references:

http://bugs.mysql.com/bug.php?id=818
http://bugs.mysql.com/bug.php?id=4670

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

1. You can find dynamic client libraries in the rpm (but not in the tarball)
2. From now on - that is from 4.1.11 - static client libraries for x86_64 will be built with -fPIC

This bug is still open in a open view. It's fixed for libmysqlclient.a but not for libmysqlclient_r.a which has the same issue.

see https://bugs.gentoo.org/show_bug.cgi?id=141999 and https://bugs.gentoo.org/show_bug.cgi?id=88360

can we please re-open this bug? It is only fixed halfway...

Reopened upon request.

Simon,

what do you mean? Problem is not fixed for libmysqlclient_r.a or something else?

Yep. As described by Christian Korff:

"It's fixed for libmysqlclient.a but not
for libmysqlclient_r.a which has the same issue."

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Please, specify exact MySQL versions where you have this problem. According to our logs I had found all the latest 4.1.x are built with -fPIC for all *.o files that form libmysqlclient_r.a on x86_64 platforms.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

The problem still exists with mysql-5.0.26:

/usr/lib64/mysql/libmysqlclient.a(libmysql.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/mysql/libmysqlclient.a: could not read symbols: Bad value

Folks, anyone care to explain what kind of feedback do you expect? It's been clearly and repeatedly stated that it's *still* an issue and what's exactly the issue... And yes, 5.0.34 is *still* affected by this bug.

All reporters,

Please, try to repeat with the latest versions, 5.0.37/5.0.38 and/or 4.1.22, and inform about the results.

Sorry, nothing new. It's still broken exactly the same way w/ 5.0.38.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Feedback was provided.

Note that according to configure logs --with-pic was used for building 5.0.38, 5.0.40 and 5.0.41 (.tar.gz binaries at least). Our mysqlclient.a library should be relocatable in this versions.

What exact binaries you had used? RPMs or tar.gz?

Could you please specify what exact package? Just checked the packages

  mysql-enterprise-gpl-5.0.38-linux-x86_64-glibc23.tar.gz
  mysql-enterprise-gpl-5.0.38-linux-x86_64-icc-glibc23.tar.gz
  MySQL-devel-enterprise-gpl-5.0.38-0.rhel3.x86_64.rpm
  MySQL-devel-enterprise-gpl-5.0.38-0.rhel4.x86_64.rpm
  MySQL-devel-enterprise-gpl-5.0.38-0.sles10.x86_64.rpm
  MySQL-devel-enterprise-gpl-5.0.38-0.sles9.x86_64.rpm

with both objdump on all the extracted .o files

  objdump -r *.o | fgrep R_X86_64_32 | fgrep -v .debug

and by creating shared libraries from the static ones

  ld -G -o libmysqlclient_r.so -z allextract libmysqlclient_r.a

and can't find any problems.

I now also verified the created shared library could be loaded.
The direct invocation of "ld -G" didn't produce a correct
shared library, instead I now extraceted the .o files, and used

 gcc -shared -o libfoo.so *.o
 dltest `pwd`/libfoo.so

The "dltest" executable uses dlopen to load the shared
library, all successful.

But there could still be problems not seen in the tests
above, because of this I'm very interested what exact
package name you installed and used that gives this
problem.

Well, sorry folks but I really fail to see what additional feedback are you requesting over and over again. Yes, it's _still_ broken exactly the same, as https://bugs.gentoo.org/show_bug.cgi?id=88360 suggests.

(Oh, and none of the packages mentioned above. Gentoo compiles mysql from source, not using any binaries.)

Jakub,

Please, check configure options and build logs of Gentoo builds then. Do they use --with-pic configure option?

MySQL AB can't control what options are used on Gentoo
when compiling from source. To clarify

 - If build of shared libraries is enabled, and the driver/module
   is linked against this shared library, there is no problem.

 - If build of shared libraries is *not* enabled, the only
   library produced is the static one, and static
   libraries are normally compiled position *dependent*, and
   can't be used part of linking a driver/module, i.e. another
   shared library.

 - There is a configure option --with-pic that makes static
   libraries position independent on platforms that supports it.

So the options compiling from source on gentoo, is to configure with

  --enable-shared

    and link with the shared library produced, or

  --disable-shared --with-pic

    and link with the static library produced

Hope this made this more clear.

If you don't control the settings, please contact the
maintainer of the Gentoo MySQL port.