On 2022-11-23 John Paul Adrian Glaubitz wrote: > On 11/23/22 12:31, Lasse Collin wrote: > > (1) Does this make the problem go away? > > Yes, that fixes the linker problem for me. At least in the case of > mariadb-10.6.
Why does it want static liblzma.a in the first place? It sounds weird to require rebuilding of mariadb-10.6 every time liblzma is updated. Can it build against liblzma.so if liblzma.a isn't available? It is fine to build *static* liblzma with --disable-symbol-versions on all archs. Debian-specific workaround is fine in the short term but this should be fixed upstream. One method would be to disable the extra symbols on ia64 but that is not a real fix. Perhaps it's not really possible as long as the main build system is Autotools, I don't currently know. I'm still curious why exactly one symbol (lzma_get_progress) looks special in the readelf output. For some reason no other symbols with the symver declarations are there. Does it happen because of something in XZ Utils or is it weird behavior in the toolchain that creates the static lib. One can wonder if it was a mistake to try to clean up the issues that started from the RHEL/CentOS 7 patch since now it has created a new problem. On the other hand, the same could have happened if this kind of symbol versioning had been done to avoid bumping the soname (which hopefully will never happen though). -- Lasse Collin
