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?