Bug 1778236
| Summary: | Problems linking to zlib corrected if zlib is linked with -Bsymbolic-functions | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Paulo Andrade <pandrade> |
| Component: | zlib | Assignee: | Ondrej Dubaj <odubaj> |
| Status: | CLOSED WONTFIX | QA Contact: | RHEL CS Apps Subsystem QE <rhel-cs-apps-subsystem-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | databases-maint, odubaj, panovotn, pbhoot, praiskup |
| Target Milestone: | rc | Keywords: | Patch |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-01-29 13:15:49 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Paulo Andrade
2019-11-29 14:43:27 UTC
Hello, sending build of of zlib with -Bsymbolic-functions flag added to LDFLAGS https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=25070902 Can you please point to a version of debian package of zlib, where this flag is used? Thank you! Can you please install and test these new RPMs and tell, if it solves your issues? Thank you. Hi, At least Ubuntu 18.0.4 and newer have this default: $ dpkg-buildflags --get LDFLAGS -Wl,-Bsymbolic-functions -Wl,-z,relro Still uncertain if it is also default on Debian. Googleing for this and it appears to be the default also to Debian for some time. I came to the same conclusion. Are the newly-built RPMs resolving your issue? Can you test them? From my point of view it should work, but I do not have a reproducer to test them. On initial tests, the user confirms everything appears to work as expected. Still waiting for extra feedback when they test their entire workflow. Good to hear that, we are considering adding this feature to rhel-8, as rhel-7.9 won't get any updates, which do not appear as critical. Is it a solution for you issue? Thanks for your reply. (In reply to Ondrej Dubaj from comment #8) > Good to hear that, we are considering adding this feature to rhel-8, as > rhel-7.9 won't get any updates, which do not appear as critical. Is it a > solution for you issue? > Thanks for your reply. The user is expecting this for rhel7, as they now have the test package installed, and if there is an update, the problem will happen again. I understand, can you please provide a concrete use-case or a reproducer, where we can test this issue? As you said, it is really a corner case and we are not aiming such things for rhel-7.9, as it should contain only high priority and critical issues. Is it a solution for you to resolve this issue in rhel-8 ? It is third party software. It works on recent Ubuntu (and I believe Debian) that now have this default: $ dpkg-buildflags --get LDFLAGS -Wl,-Bsymbolic-functions -Wl,-z,relro There is an example of the problem at https://github.com/madler/zlib/issues/454 that somewhat mimic what the user is experiencing. The issue should be either, the user has software with 2 versions of zlib, or a symbol somewhere that have a name clashing with a zlib symbol. Zlib, at least as of version 1.2.7 has broken symbol versioning, at least of the deflateReset symbol, that is what the github issue shows. I suspect Ubuntu is using -Bsymbolic-functions to solve issues with third party software, but mainly due to its side effect of less relocations: Ubuntu: $ readelf -r libz.so.1.2.11 Relocation section '.rela.plt' at offset 0x1d88 contains 17 entries: ... RHEL7: $ readelf -r libz.so.1.2.7 Relocation section '.rela.plt' at offset 0x1a10 contains 46 entries: ... Can you please explain, how it is possible to have 2 versions of zlib installed? Are both those versions shipped by RedHat? Or if there are only 2 versions of symbol installed on a system. Can you please say, which symbols are causing the problem? Thank you. This specific case is a proprietary binary, that from my understanding is very complex, apparently some shared objects are linked to one version of zlib and shared objects that use the system zlib trigger the problem with the deflateReset symbol. I may understand the issue. But from my point of view it is really a corner case, which does not seem to be a candidate for rhel-7.9 fix. Are those shared objects which are linked to final binary shipped by RedHat, or is it some kind of third party software? From the discussion, I understand that you already have a workaround for this problem. Can you confirm that? These are a large set of binaries from different vendors. The problematic ones are not shipped by Red Hat from what I understood. The workaround so far was the test build from comment #2. If the shared objects are not shipped by RedHat, this is not a case which we want to support. If there is an existing workaround for rhel-7, we will consider this enhancement for rhel-8.3, but not for rhel-7. Closing this bug as CLOSED:WONTFIX. If there is another business reason to resolve this issue, please feel free to reopen this bug and we will consider fixing it. |