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

[24 Feb 2005 22:30] Ryan Heule
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.
[25 Feb 2005 19:53] Sergei Golubchik
related references:

http://bugs.mysql.com/bug.php?id=818
http://bugs.mysql.com/bug.php?id=4670
[25 Feb 2005 21:10] Sergei Golubchik
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
[2 Aug 2006 15:17] Christian Korff
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
[20 Sep 2006 17:46] Simon Stelling
can we please re-open this bug? It is only fixed halfway...
[20 Sep 2006 17:53] Lenz Grimmer
Reopened upon request.
[21 Sep 2006 11:33] Valeriy Kravchuk
Simon,

what do you mean? Problem is not fixed for libmysqlclient_r.a or something else?
[18 Oct 2006 9:31] Simon Stelling
Yep. As described by Christian Korff:

"It's fixed for libmysqlclient.a but not
for libmysqlclient_r.a which has the same issue."
[21 Oct 2006 23:00] Bugs System
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".
[25 Nov 2006 9:46] Valeriy Kravchuk
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.
[26 Dec 2006 0:00] Bugs System
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".
[3 Feb 2007 17:04] Simon Stelling
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
[8 Apr 2007 20:27] Jakub Moc
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.
[9 Apr 2007 15:17] Valeriy Kravchuk
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.
[16 Apr 2007 14:13] Jakub Moc
Sorry, nothing new. It's still broken exactly the same way w/ 5.0.38.
[9 May 2007 23:00] Bugs System
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".
[9 May 2007 23:43] MySQL Verification Team
Feedback was provided.
[23 May 2007 9:24] Valeriy Kravchuk
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?
[23 May 2007 9:53] Kent Boortz
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.
[23 May 2007 10:11] Kent Boortz
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.
[23 May 2007 16:13] Jakub Moc
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.
[23 May 2007 16:15] Jakub Moc
(Oh, and none of the packages mentioned above. Gentoo compiles mysql from source, not using any binaries.)
[23 May 2007 19:49] Valeriy Kravchuk
Jakub,

Please, check configure options and build logs of Gentoo builds then. Do they use --with-pic configure option?
[23 May 2007 20:50] Kent Boortz
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.