Bugzilla – Bug 1218620
cmake: -Wl,--no-undefined breaks canokey-qemu build
Last modified: 2024-03-25 11:46:15 UTC
The recent addition of -Wl,--no-undefined to link flags for shared libraries breaks build of the canokey-qemu package. I've tried to fix it but hit my limits wrt cmake knowledge. Advice needed. The issue here is that the package produces an actual shared library, not a module. Qemu links against it. Nevertheless AFAICT it has symbols that come from the qemu binary itself. Probably dirty but that's the way it is: https://build.opensuse.org/package/show/openSUSE:Factory/canokey-qemu Is there a way to either unset --no-undefined or adjust the cmake config there?
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