On 2022-11-23 John Paul Adrian Glaubitz wrote:
> I guess the additional unwind section breaks your workaround, so the
> best might be to just disable this workaround on ia64 using the
> configure flag, no?
There currently is no configure option to only disable the CentOS 7
workaround symbols. They are enabled if $host_os matches linux* and
--disable-symbol-versions wasn't used. Disabling symbol versions from
liblzma.so.5 will cause problems as they have been used since 5.2.0 and
many programs and libraries will expect to find XZ_5.0 and XZ_5.2.
Having the symbol versions in a static library doesn't make much sense
though. Perhaps this is a bug in XZ Utils. As a test, the static
liblzma.a could be built without symbol versions with --disable-shared
--disable-symbol-versions:
(1) Does this make the problem go away?
(2) Do the failing builds even require that liblzma.a is present
on the system?
I don't now how to avoid symvers in a static library as, to my
understanding, GNU Libtool doesn't add any -DBUILDING_SHARED_LIBRARY
kind of flag which would allow using a #ifdef to know when to use the
symbol versions. Libtool does add -DDLL_EXPORT when building a shared
library on Windows but that's not useful here.
(Switching to another build system would avoid some other Libtool
problems too like wrong shared library versioning on some OSes. However,
Autotools-based build system is able to produce usable xz on quite a
few less-common systems that some other build systems don't support.)
A workaround to this workaround could be to disable the CentOS 7
symbols on ia64 by default. Adding an explicit configure option is
possible too, if needed. But the first step should be to understand
what is going on since the same problem could appear in the future if
symbol versions are used for providing compatibility with an actual ABI
change (hopefully not needed but still).
> Older versions are available through Debian Snapshots:
>
> > http://snapshot.debian.org/package/xz-utils/
liblzma.a in liblzma-dev_5.2.5-2.1_ia64.deb doesn't have any "@XZ" in
it which is expected. This looks normal:
<lzma_get_progress>: [0x18c0-0x1990], info at +0x100
> > Many other functions are listed in those .IA_64.unwind
> > sections too but lzma_get_progress is the only one that has "@XZ"
> > as part of the function name.
>
> Hmm, that definitely seems the problem. Could it be that the symbols
> that are exported on ia64 need some additional naming?
It seems weird why only one symbol is affected. Perhaps it's a bug in
the toolchain creating liblzma.a. However, perhaps the main bug is that
XZ Utils build puts symbol versions into a static liblzma. :-(
> I think we can waive for CentOS 7 compatibility on Debian unstable
> ia64 😉.
There is no official CentOS 7 for ia64 but that isn't the whole story
as the broken patch has been used elsewhere too. Not having those extra
symbols would still be fine in practice. :-)
--
Lasse Collin
