Alexey Serbin has uploaded this change for review. ( http://gerrit.cloudera.org:8080/24116
Change subject: [client] make zlib's compress symbols local in libkudu_client ...................................................................... [client] make zlib's compress symbols local in libkudu_client Before this patch, The client_symbol-test on RHEL9.6 x86_84 was failing because of the compress zlib's symbols not being local: Found bad symbol 'compress' Found bad symbol 'compress2' Found bad symbol 'compressBound' That's only with the very recent src from the master branch: 1.18.0, 1.18.1 and 1.18.x versions do not have such an issue. Also, this isn't an issue at least on RHEL8.8 and Ubuntu 24.04 LTS with the same sources. I didn't do RCA to understand what's the underlying reason, but [1] looks like one of the usual suspects because of the changes to the linker type in use. The other contributing factor might be the fact that the system libz is also linked in as a dynamic library (that's been so for quite some time, it seems). Why to link system libz when we do have our own in 3rd-party? It's a good question: unless I'm missing something, it should be addressed in a separate changelist. We either need to fix linker search paths for zlib or switch to the OS-provided zlib (perhaps, the former). This patch is to address the inconsistency in the set of available symbols in the kudu_client library and fix the recently discovered client_symbol-test's failure. [1] https://github.com/apache/kudu/commit/1d789a87a Change-Id: I78f1c38772050c6fd588141dc6aa499708b87fc5 --- M src/kudu/client/symbols.map 1 file changed, 1 insertion(+), 0 deletions(-) git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/16/24116/1 -- To view, visit http://gerrit.cloudera.org:8080/24116 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: newchange Gerrit-Change-Id: I78f1c38772050c6fd588141dc6aa499708b87fc5 Gerrit-Change-Number: 24116 Gerrit-PatchSet: 1 Gerrit-Owner: Alexey Serbin <[email protected]>
