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

Reply via email to