A recent bug report indicated that builds of Python 3.14 from a
buildroot that included expat 2.7.2 could be deployed on systems that
had older builds of expat installed. That would lead to something like:
>>> import pyexpat
Traceback...
ImportError: ...pyexpat.cpython-314-x86_64-linux-gnu.so: undefined
symbol: XML_SetAllocTrackerActivationThreshold
The python 3.14 package has been modified to generate a runtime
requirement on a version at least as new as the one in the build root:
https://src.fedoraproject.org/rpms/python3.14/c/8236063d9f0539e2ac7df38c8d0313c37bc7d39a?branch=rawhide
Another way to solve the problem would be to offer the upstream project
versioned symbols.. probably something like this (but I've probably got
the cmake config wrong):
https://github.com/gordonmessmer/libexpat/commit/813248dd89d1f9e88661094c11b867aae6bece36
I would guess that it wouldn't be hard to convince libexpat to adopt
versioned symbols, since they already maintain a substantially similar
file for MS VC++
... but even if we encourage upstream projects to adopt versioned
symbols, I think rpm should do something better for the libraries that
haven't adopted them, in the meantime.
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
