* Marcel Plch: > On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote >> If you take the address of a local variable and pass the resulting >> pointer to another function, the compiler will generate a call to >> __stack_chk_fail, which lives in glibc. At build time, linking >> against >> glibc is required so that this symbol receives its proper version, >> otherwise the resulting binary is invalid and may not be compatible >> with >> future glibc versions. >> >> Thanks, >> Florian > > Since the extensions get the symbols from the Python interpreter on > dynamic load, I can see the risk here in case of third-party software, > where the interpreter gets recompiled against a new glibc version and > the extension is left alone. However, the extensions are recompiled > whenever the interpreter is and so will always be compatible with the > 'current' glibc version. There is no need to keep an eye out for future > versions. Or is there? It's certainly possible to run an old Python binary with a newer glibc. How do you even get an extension that is not linked against glibc when it uses symbols from glibc? Do you build extensions with -nostdlib? Or invoke ld directly, instead of gcc/g++? Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
