|
Bugzilla – Full Text Bug Listing |
| Summary: | cmake: -Wl,--no-undefined breaks canokey-qemu build | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Ludwig Nussel <lnussel> |
| Component: | Development | Assignee: | Stefan Brüns <stefan.bruens> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P1 - Urgent | CC: | dfaggioli, dmueller, simonf.lees |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Ludwig Nussel
2024-01-08 14:38:36 UTC
Yes, that "library" is quite a design nightmare. It should pass in the needed callbacks when the library gets initialized, instead of relying on the symbols being present. The simplest workaround it likely to switch the "add_library(... SHARED)" calls to "MODULE". I tried that but then it gets installed without soname any other ideas how to fix the package? You can just append the parameter again after the %cmake_macro, with changed values. which parameter? Short of a proper solution I've filed https://build.opensuse.org/request/show/1139744 Why does cmake override the default optflags anyway? If -Wl,--no-undefined is useful, shouldn't we also have it in all build systems? It's worth noting that adding -Wl,--no-undefined is not a recent change, it has been present in SLE-15 for a long time, so reverting it here again will mean Factory will stop catching a class of issues here. This is an autogenerated message for OBS integration: This bug (1218620) was mentioned in https://build.opensuse.org/request/show/1139983 Factory / cmake (In reply to Ludwig Nussel from comment #6) > Short of a proper solution I've filed > https://build.opensuse.org/request/show/1139744 > > Why does cmake override the default optflags anyway? If -Wl,--no-undefined > is useful, shouldn't we also have it in all build systems? Because e.g. autotools does not have separate linker flags for executables, shared libraries, and dlopen'ed modules/plugins. I don't mind having this enabled. As packager with only most basic cmake knowledge it hit me out of the blue. I'd really appreciate an announcement and some docu what do to do in case of trouble. Something like eg. https://en.opensuse.org/openSUSE:LTO In the end we need canokey-qemu fixed. (In reply to Ludwig Nussel from comment #10) > In the end we need canokey-qemu fixed. > Indeed. In fact, this --canokey-qemu not building, I mean-- is even blocking QEMU 8.2 from getting into Factory (which I need it for SLE15-SP6, for confidential computing stuff, and for other things)... (In reply to Dario Faggioli from comment #11) > (In reply to Ludwig Nussel from comment #10) > > In the end we need canokey-qemu fixed. > > > Indeed. In fact, this --canokey-qemu not building, I mean-- is even blocking > QEMU 8.2 from getting into Factory (which I need it for SLE15-SP6, for > confidential computing stuff, and for other things)... 1. There is a pending SR (1140009) to fix the canokey-qemu build, without bad side effects on the rest of the distribution. The SR has not received any attention, yet ... 2. As far as I understand, canokey-qemu is a new, and optional dependency of qemu. 3. SLE had and still has '-Wl,--no-undefined' set in the linker flags, so trying to build canokey-qemu on SLE will fail. https://build.opensuse.org/request/show/1140009 Thanks! I've accepted the the request. However I really don't like overriding CMAKE_SHARED_LINKER_FLAGS completely. Would be much better if it's value would be available in eg a macro so we could specifically remove --no-undefined from it. That way future extensions would still also affect the package. (In reply to Stefan Brüns from comment #12) > (In reply to Dario Faggioli from comment #11) > > (In reply to Ludwig Nussel from comment #10) > > > In the end we need canokey-qemu fixed. > > > > > Indeed. In fact, this --canokey-qemu not building, I mean-- is even blocking > > QEMU 8.2 from getting into Factory (which I need it for SLE15-SP6, for > > confidential computing stuff, and for other things)... > > 1. There is a pending SR (1140009) to fix the canokey-qemu build, without > bad side effects on the rest of the distribution. The SR has not received > any attention, yet ... > Ok, cool, thanks. > 2. As far as I understand, canokey-qemu is a new, and optional dependency of > qemu. > Well, yes, it's optional. And in Factory/Tumbleweed, we opt for it. :-) > 3. SLE had and still has '-Wl,--no-undefined' set in the linker flags, so > trying to build canokey-qemu on SLE will fail. > The package is not even there in SLE, AFAIK. In fact, in SLE, canokey support is disabled, so this should not be a problem This is an autogenerated message for OBS integration: This bug (1218620) was mentioned in https://build.opensuse.org/request/show/1141265 Factory / canokey-qemu Stefan, how about this: https://build.opensuse.org/request/show/1141514 This is fixed, and we can close it, right? ludwig added patches to canokey-qemu |