Bug 1770160
Summary: | gs: symbol lookup error: /lib64/libgs.so.9: undefined symbol: jbig2_ctx_new | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nicolas Mailhot <nicolas.mailhot> |
Component: | jbig2dec | Assignee: | Michael J Gruber <mjg> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | mjg, pzhukov, rjones |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-12-14 22:04:32 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
Nicolas Mailhot
2019-11-08 10:58:28 UTC
jbig2dec-libs-0.17 is supposed to be abi-compatible with 0.16. Does the problem go away if you downgrade jbig2dec-libs? If yes then we need to coordinate the updates for gs and jbig2dec - I'm sorry for jumping ahead with jbig2dec. While I'm to blame for that, technically this bug will be resolved by resolving bug #1761792 (gs update), so I'll set dependencies accordingly. But we (I) need to coordinate this for future updates. Suggestions welcome. dnf downgrade jbig2dec-libs-0.16-1.fc32.x86_64.rpm works Thanks for the pointer. Scratch build in progress. The local build contains the mssing symbol after the patch. Please test with jbig2dec-0.17-2.fc32. ghostscript-9.27-2.fc32.x86_64 libgs-9.27-2.fc32.x86_64 jbig2dec-0.17-2.fc32.x86_64 $ gs --help gs: symbol lookup error: /lib64/libgs.so.9: undefined symbol: jbig2_ctx_new_imp Is there any further suggestion to fix this? (In reply to Richard W.M. Jones from comment #6) > ghostscript-9.27-2.fc32.x86_64 > libgs-9.27-2.fc32.x86_64 > jbig2dec-0.17-2.fc32.x86_64 > > $ gs --help > gs: symbol lookup error: /lib64/libgs.so.9: undefined symbol: > jbig2_ctx_new_imp > > Is there any further suggestion to fix this? Well, this is the first answer to my request for testing. That is why jbig2dec-0.17-2.fc32.x86_64 is in rawhide only so far and ON_QA. Second, this is weird: With jbig2dec-0.16-1.fc31 on F31: nm -DC /usr/lib64/libjbig2dec.so.0.0.0|grep jbig2_ctx 0000000000005230 T jbig2_ctx_free 0000000000005050 T jbig2_ctx_new ghostscript-9.27-2.fc31.x86_64 is perfectly happy with that. With jbig2dec-0.17-2.fc32 built on F31: nm -DC jbig2dec-0.17/.libs/libjbig2dec.so.0.0.0 |grep jbig2_ctx 0000000000005310 T jbig2_ctx_free 00000000000052f0 T jbig2_ctx_new 0000000000005070 T jbig2_ctx_new_imp So, jbig2_ctx_new_imp never was there in jbig2dec-0.16 to begin with, and while upstream dumped jbig2_ctx_new in 0.17, -2 of my package restores it and _imp (using the debian fix). What symbols does your installed libjbig2dec define? Aha .. $ rpm -qa | grep jbig2 jbig2dec-libs-0.14-6.fc31.x86_64 jbig2dec-0.17-2.fc32.x86_64 It looks like you are missing this from your libs subpackage: Requires: %{name}%{?_isa} = %{version}-%{release} Note this is generally advised by Fedora packaging guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_requiring_base_package Once I manually installed jbig2dec-libs-0.17-2.fc32.x86_64 it does actually work. (In reply to Richard W.M. Jones from comment #8) > Aha .. > > $ rpm -qa | grep jbig2 > jbig2dec-libs-0.14-6.fc31.x86_64 > jbig2dec-0.17-2.fc32.x86_64 That explains it, thanks. So this rawhide installation was not fully up-to-date - or is this F31 with some F32 packages? > It looks like you are missing this from your libs subpackage: > > Requires: %{name}%{?_isa} = %{version}-%{release} > > Note this is generally advised by Fedora packaging guidelines: > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > #_requiring_base_package It also says that -libs does not need that unless -libs depends on functionality of the base package. Note that it is perfectly okay to use -libs without the base package. In fact, that is what all programs linking against libjbig2dec will depend on. So, adding that requires only means that these programs will pull in the jbig2dec binary for no intrinsic reason. It would not have helped your case - you apparantly installed jbig2dec-0.17-2.fc32.x86_64 without updates enabled, and the dependency of jbig2dec on jbig2dec-libs was formally satisfied by jbig2dec-libs-0.14-6.fc31.x86_64. This would not have changed (for your existing install, with a newer jbig2dec with your requested requires). So, if anything, then jbig2dec (and all other programs linking against libjbig2dec) should depend on the exact jbig2dec-libs. Well, they do depend on the .so version, and the upstream ABI change is what brought us here. In conclusion, this bug seems to be fixed in rawhide "proper", and I intend to mark it as such and push to F31. But I'll wait a few days for replies just in case I overlooked something in my analysis above. Hi, I had to reinstall the system that had the problem due to the glibc/firefox breakage. So, I can no longer test in the exact same configuration. On the new rawhide system, printing works (with a new printer setup, no idea if it’s the very same as before) I'd suggest making jbig2dec depend on the exact -libs package. Is there any situation where you'd want them to be at a different version? It sounds like trouble. (In reply to Richard W.M. Jones from comment #11) > I'd suggest making jbig2dec depend on the exact -libs package. Is there any > situation where you'd want them to be at a different version? It sounds like > trouble. No, it's just that usually dependencies on libs are picked up automatically and this works unless ABI breaks or someone breaks the update process... So, you are suggesting Requires: %{name}-libs%{?_isa} = %{version}-%{release} for package jbig2dec, right? (In reply to Michael J Gruber from comment #12) > (In reply to Richard W.M. Jones from comment #11) > > I'd suggest making jbig2dec depend on the exact -libs package. Is there any > > situation where you'd want them to be at a different version? It sounds like > > trouble. > > No, it's just that usually dependencies on libs are picked up automatically > and this works unless ABI breaks or someone breaks the update process... Dependencies on libs only work correctly if the library does symbol versioning (and does it properly). jbig2dec-libs doesn't do it properly as you can see if you run: $ nm -D --with-symbol-versions /usr/lib64/libjbig2dec.so.0.0.0 | less Compare it to a library I wrote which does symbol versioning: $ nm -D --with-symbol-versions /usr/lib64/libnbd.so.0.0.0 | less Without proper symbol versioning RPM only adds a basic dependency: libjbig2dec.so.0()(64bit) which of course causes problems as we've seen here. With symbol versioning you get dependencies like: libnbd.so.0()(64bit) libnbd.so.0(LIBNBD_1.0)(64bit) libnbd.so.0(LIBNBD_1.2)(64bit) that ensure the updated library is pulled in when symbols are added or changed. > So, you are suggesting > > Requires: %{name}-libs%{?_isa} = %{version}-%{release} > > for package jbig2dec, right? Yes. |