On 16. 01. 26 11:18, Florian Weimer wrote:
* Gordon Messmer:
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
Another possibility would be to make the symbol reference weak in
Python, and use the functionality only if it is available in the
installed version of Expat.
You can think of it as a slightly more type-safe version of dlsym.
You'd write
#pragma weak XML_SetAllocTrackerActivationThreshold
and then before calling the function, you'd check
if (XML_SetAllocTrackerActivationThreshold != NULL) {
// Use new functionality here.
} else {
// Other code, presumably with vulnerability.
}
I assume the two code paths already exist because Python can still build
with the old version of Expat. In a sense, it's just a matter of moving
the check from compile to run time.
Weak symbols currently do not work as expected with versioned symbols
because BFD ld always generates a strong version reference, even if all
symbol references using that version are weak. On the glibc side, we
support weak version references, but the code is not tested because we
do not have any binaries to test them with.
Of course this is fixable, it's just that no one has implemented it.
BFD ld does not set VER_FLG_WEAK on version reference if all symbols
are weak
<https://sourceware.org/bugzilla/show_bug.cgi?id=24718>
(The problematic glibc consistency check mentioned comment 16 is already
gone.)
Thanks. I have in my TODO to go to Python upstream and ask them whether they
would be willing to move the checks form buidltime to runtime. This might be a
way to do it.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
_______________________________________________
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
