On Tue, 2019-02-12 at 15:35 +0100, Florian Weimer wrote: > * 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 I see your point. So rather than: "Python extension modules don't need to be linked against libc as they are never actually loaded on their own, but rather from the Python interpreter," we can say: "Some Python extension modules don't need to be linked against glibc under such condition that they don't use any glibc symbol." Correct? _______________________________________________ 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
