* 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
> glibc is required so that this symbol receives its proper version,
> otherwise the resulting binary is invalid and may not be compatible
> future glibc versions.
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++?