MySQL Bugs: #16595: zlib linking problems

Bug #16595	zlib linking problems
Submitted:	18 Jan 2006 8:44	Modified:	24 Sep 2007 12:30
Reporter:	Lenz Grimmer	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S3 (Non-critical)
Version:	4.1.16, 4.1.19, 5.0.45	OS:	Linux (RHEL3)
Assigned to:		CPU Architecture:	Any

Description:
I received this report from a user via email:

[SNIP]
Not sure if this is a PHP or MySQL issue, but I am having problems
re-compiling PHP 5.0.5 after upgrading to the 4.1.16-1 set of MySQL RPM's
which were posted on Dec 25, 2005.  I previously had version 4.1.16-0 which
worked fine.  It appears to be a zlib conflict of some sort as I am
compiling PHP with '--with-mysqli=/usr/bin/mysql_config' and '--with=zlib'.
After I install MySQL-devel-4.1.16-1.glibc23.i386.rpm, during the PHP
compilation process, I get the error:

grep: /usr/lib/mysql/libz.la: No such file or directory
/bin/sed: can't read /usr/lib/mysql/libz.la: No such file or directory
libtool: link: `/usr/lib/mysql/libz.la' is not a valid libtool archive

I also tried the MySQL-devel-standard-4.1.16-1.rhel3.i386.rpm package and
with that, I get errors:

/usr/lib/mysql/libz.a(adler32.o)(.text+0x0): In function `adler32': 
: multiple definition of `adler32'
/usr/lib/mysql/libz.a(adler32.o)(.text+0x0): first defined here
/usr/lib/mysql/libz.a(adler32.o)(.text+0x250): In function `adler32_combine':
: multiple definition of `adler32_combine'
/usr/lib/mysql/libz.a(adler32.o)(.text+0x250): first defined here
/usr/lib/mysql/libz.a(compress.o)(.text+0x0): In function `compress2':
: multiple definition of `compress2'
/usr/lib/mysql/libz.a(compress.o)(.text+0x0): first defined here
..

Did something change in the 4.1.16-1 RPM's in regards to zlib?  As I
mentioned above, 4.1.16-0 worked fine.
[SNIP]

How to repeat:
See above.

I was the one who originally reported this issue to Lenz.  I just tried the new version 4.1.18 released today and I ran into the same issue using the RHEL3 (x86) set of RPM's.  Please let me know if I can provide any more information or can assist in any way.  Thanks.

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".

This problem persists in 4.1.19 for RHEL3. To solve the problem I have to uninstall mysql-devel and reinstall a version below 4.1.16 of mysql-devel.

I ran into the same issue trying to 5.0.19 and connector 3.51.12.  A few things that I noticed when compiling were:

1) There are 2 "-lz" options passed to libtool right before the compile dies.
/bin/sh ../libtool --tag=CC --mode=link gcc  -O3 -DDBUG_OFF   -I/usr/include/mysql -g -pipe -march=i386 -mcpu=i686   -o libmyodbc3.la -rpath /usr/local/lib -release 3.51.12 catalog.lo connect.lo cursor.lo dll.lo error.lo execute.lo handle.lo info.lo myodbc3.lo options.lo prepare.lo results.lo transact.lo utility.lo -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm ../util/libmyodbcutil.la -L/usr/local//lib -lz  -lodbcinst

2) On the gcc line where the compile dies, there are 2 "/usr/lib/mysql/libz.a" libs passed to gcc.  If you remove one of them and try that line by hand, it works.
gcc -shared  .libs/catalog.o .libs/connect.o .libs/cursor.o .libs/dll.o .libs/error.o .libs/execute.o .libs/handle.o .libs/info.o .libs/myodbc3.o .libs/options.o .libs/prepare.o .libs/results.o .libs/transact.o .libs/utility.o -Wl,--whole-archive ../util/.libs/libmyodbcutil.a /usr/lib/mysql/libmysqlclient.a /usr/lib/mysql/libz.a /usr/lib/mysql/libz.a -Wl,--no-whole-archive  -L/usr/lib/mysql -lcrypt -lnsl -lm /usr/lib/libltdl.so -ldl -L/usr/local//lib -lodbcinst  -march=i386 -mcpu=i686 -Wl,-soname -Wl,libmyodbc3-3.51.12.so -o .libs/libmyodbc3-3.51.12.so

3) For some reason post 4.1.16, MySQL comes with it's own version of libz.a as you can see based on the path that libtool is picking up (Also verified by checking the rpms that were installed).  A previous comment says to back rev to 4.1.16 and the compile goes through with no errors which is correct, but there are fixes in 4.1.19/5.0.19 (bug#6536 & bug#11892) that help with the MyODBC connector issues.

4) My hack/workaround was to remove/comment out the zlib check in the configure script.  For mysql-connector-odbc-3.51.12 they are lines 19782 - 19853 (or just search for "-lz").  After doing that, the libtool only has a single "-lz" option and subsequently gcc only tries to compile in a single /usr/lib/mysql/libz.a.

Hope that helps.

I just wanted to find out if there were any updates on this?  I am still running into the same issue on RHEL4 using MySQL-devel-community-5.0.45-0.rhel4.

Thank you for the report.

Please provide exact configure line you use to compile PHP. Also confirm you use binary version of MySQL and provide accurate version of package you use (file name).

I ran some additional tests and found out that this behavior only occurred on the older PHP 5.0.5 release that I was using.  I didn't run into any issues when upgrading to the latest PHP 5.2.4.  I believe this bug can now be closed.  Thanks for your help.

Thank you, Ryan, for the feedback.

The bug is closed as "Can't repeat" according to the last comment.