#243 Static link still depends on shared library (Linux)

[Greg Ward]

I'm trying to build MySQL-python 1.2.2 statically on Red Hat Enterprise Linux 3.0. I edited site.cfg and set "static = True". When I build with this command:

$ python2.5 setup.py build_ext -f

the link command ends up being

gcc -pthread -shared build/temp.linux-i686-2.5/_mysql.o /usr/lib/mysql/libmysqlclient.a -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -o build/lib.linux-i686-2.5/_mysql.so

Note that it's linking with libmysqlclient.a (good) as well as "-lmysql" (bad). The resulting .so file appears to be both statically linked (it's 309k rather than ~112k) and dynamically linked (ldd reports that it depends on /usr/lib/mysql/libmysqlclient.so.10).

This is with a local build of Python 2.5.1 and a local build of gcc 3.2.1, all running on RHEL 3.0 using Red Hat's package of the MySQL client libs (mysql-3.23.58-16.RHEL3.1). Yes, I know this is mostly ancient code; we're still stuck with this as our basic build platform for reasons I won't elaborate here.

[Greg Ward]

patch for setup_posix.py

[Greg Ward]

Logged In: YES
user_id=14422
Originator: YES

Luckily the fix appears really simple: just remove the MySQL client lib from the 'libraries' list, which means distutils will not generate the "-lmysql" option -- the explicit "libmysql.a" in extra_objects replaces it completely. Patch attached.

File Added: sf1878264.patch

[Greg Ward]

Logged In: YES
user_id=14422
Originator: YES

Note that my patch assumes library_dirs[0] is the MySQL library dir, which bug #1834305 (static link on FreeBSD) shows is not the case.

[Andy Dustman]

Probably not fixing for 1.2. 1.3/2.0 will be much more flexible about being able to pick which driver to use at runtime.