Alexey Serbin created KUDU-3756:
-----------------------------------
Summary: Clarify on libz (a.k.a. zlib) linkage in binaries and
kudu_client library
Key: KUDU-3756
URL: https://issues.apache.org/jira/browse/KUDU-3756
Project: Kudu
Issue Type: Task
Components: CLI, client, master, tserver
Affects Versions: 1.18.1, 1.18.0
Reporter: Alexey Serbin
The libz library from Kudu's 3rd-party (a.k.a. zlib) is linked into
kudu-master, kudu-master, kudu CLI binaries and into the libkudu_client
library. At the same time, these binaries are linked against system libz
library (i.e. it's provided by the packaging system of the OS itself), both in
RELEASE and DEBUG build configurations:
{noformat}
# ldd bin/kudu-master | grep libz
libz.so.1 => /lib64/libz.so.1 (0x00007f3acdb60000)
# ldd bin/kudu-tserver | grep libz
libz.so.1 => /lib64/libz.so.1 (0x00007f1a3614a000)
# ldd bin/kudu | grep libz
libz.so.1 => /lib64/libz.so.1 (0x00007f0df396e000)
# ldd lib/exported/libkudu_client.so.0.1.0 | grep libz
libz.so.1 => /lib64/libz.so.1 (0x00007fe4327d4000)
{noformat}
It doesn't make much sense to have Kudu binaries statically linked aginst
3rd-party zlib and dynamically linked against the system zlib. It's necessary
to clarify on this and clean up zlib linkage: either switch to using
OS-provided zlib or rely only on the 3rd-party zlib and prevent linking to the
system zlib.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
