missing gzopen symbol for Percona-Server-shared-compat-55

Bug #1171755 reported by David Busby on 2013-04-23
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona Server moved to

Bug Description

We note that when running mydumper compiled against Percona-Server-shared-51 with --compress option, with the library provided by Percona-Server-shared-compat the error 'symbol gzopen not defined in file' occurs.

This is not the case then the library from Percona-Server-shared-51 is used.

1) Compiling against the .16 libraries provided by Percona-Server-shared-51 and running against them works without issue.
2) Compiling against the .18 libraries provided by Percona-Server-shared-compat-55 and running against them works without issue.
3) Compiling against the .16 libraries provided by Percona-Server-shared-51 and running against .16 libraries from Percona-Server-shared-compat-55 throws the error:
'symbol gzopen not defined in file'

Stewart Smith (stewart) wrote :

This seems like "not a bug" as gzopen is part of zlib and not mysql client.... what about the Oracle binaries?

Changed in percona-server:
status: New → Invalid
Changed in percona-server:
status: Invalid → Incomplete
tags: added: pkg rdba
David Busby (d-busby) wrote :

Compiled against Percona-51 then tested against MySQL-shared-compat-5.5.31-1 (same procedure as with Percona-Server-shared-compat).

completed without issue.

Changed in percona-server:
status: Incomplete → New
David Busby (d-busby) wrote :

Added a short 1:58 screen cast highlighting this issue.

David Busby (d-busby) wrote :
David Busby (d-busby) wrote :

Please advise if any more information is required on this issue; at this time it is becoming an increasing issue with compilation of our internal binaries.

David Busby (d-busby) wrote :

Per IRC Discussion for 5.5.30:

[root@localhost ~]# nm -D /usr/lib64/ | grep -i gzop
nm -D /usr/lib64/ | grep -i gzop
[root@localhost ~]# rpm -qa | grep Percona
rpm -qa | grep Percona
[root@localhost ~]# ldd /usr/lib64/
ldd /usr/lib64/ => (0x00007fff9b048000) => /lib64/ (0x00007f6eb0430000) => /lib64/ (0x00007f6eb0210000) => /lib64/ (0x00007f6eaffd8000) => /lib64/ (0x00007f6eafdb8000) => /lib64/ (0x00007f6eafb30000) => /lib64/ (0x00007f6eaf918000) => /lib64/ (0x00007f6eaf580000)
 /lib64/ (0x00007f6eb09b0000) => /lib64/ (0x00007f6eaf318000) => /lib64/ (0x00007f6eaf110000)

So, it looks like the libmysqlclient is linked against zlib (than
using the bundled one) in 5.5.30. => /lib64/ (0x00007f6eaf918000)

For an older one,
nm -D | grep -i gzop
00000000000c70c0 T gzopen

ldd => (0x00007fffc47ff000) => /lib64/ (0x00007fb771232000) => /lib64/ (0x00007fb770ffb000) => /lib64/ (0x00007fb770de1000) => /lib64/ (0x00007fb770b5d000) => /lib64/ (0x00007fb7707ca000)
        /lib64/ (0x00000037e3400000) => /lib64/ (0x00007fb770567000) => /lib64/ (0x00007fb770363000)

(The above is for 5.5.27 and the gzopen used there is the zlib
present bundled in mysql sources).

So somewhere between those versions, the linking/building has

Now, since zlib provides those symbols, mydumper should ideally
link against zlib directly. But, what function exported by
libmysqlclient is called by --compress in mydumper - that should
have linked it.

As a workaround, can you try building mydumper against zlib -- -lz?

I do not see *shared-compat* RPM for 5.6.10 at, so I assume 5.6.x is (not yet?) affected.

Percona now uses JIRA for bug reports so this bug report is migrated to:

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers