GeezerVison

Copy link

Copy Markdown

Contributor

methane reviewed Feb 21, 2017

View reviewed changes

methane requested changes Feb 22, 2017

View reviewed changes

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Uberi force-pushed the bpo-29110 branch from 932ef31 to 96fa443 Compare February 22, 2017 04:59

methane reviewed Feb 22, 2017

View reviewed changes

Uberi force-pushed the bpo-29110 branch from 96fa443 to e09c582 Compare February 22, 2017 05:14

methane approved these changes Feb 22, 2017

View reviewed changes

serhiy-storchaka reviewed Feb 23, 2017

View reviewed changes

serhiy-storchaka reviewed Feb 23, 2017

View reviewed changes

follow up of GH-162

…F file. (pythonGH-162)

(cherry picked from commit 03f68b6)

follow up of pythonGH-162
(cherry picked from commit 5dc33ee)

…F file. (pythonGH-162)

(cherry picked from commit 03f68b6)

follow up of pythonGH-162
(cherry picked from commit 5dc33ee)

(cherry picked from commit 03f68b6) (GH-162)
(cherry picked from commit 5dc33ee) (GH-293)

(cherry picked from commit 03f68b6) (GH-162)
(cherry picked from commit 5dc33ee) (GH-293)

Fixes #162

When building shared modules (*.pyd) for MinGW, they link against
the import library for the main python (e.g. -lpython3.11). When
linking shared modules on Linux, this doesn't happen, but those
shared libraries are linked with undefined references which
then are fulfilled by the host process when they are loaded.

Add a dependency to make sure that $(LDLIBRARY), e.g.
libpython$(LDVERSION).dll.a, exists before starting to build
the shared modules.

Previously, if libpython$(LDVERSION).dll.a didn't exist when
the shared modules were linked, some of them failed to link,
but this wasn't reported as an error in the build, and a
later invocation of setup.py would retry building them, which
then would succeed. E.g. there was a seemingly benign race
condition in the build.

However, in some rare cases, the race condition no longer
was benign. The build also produces a corresponding static library,
$(LIBRARY), e.g. libpython$(VERSION)$(ABIFLAGS).a - which in
the end would be named similarly, libpython3.11.a, when
$(LDLIBRARY) would be libpython3.11.dll.a.

If the static library exists but the import library doesn't, then
most modules would still fail to link, but a few ones wouldn't
(select, _multiprocessing, _overlapped and _socket). The ones
that did succeed linking with the static library would crash at
runtime though.

By making sure that the right, intended library to fulfill the
linker parameter "-lpython3.11" exists before building the shared
modules, we avoid the whole race condition that in some rare
cases could produce a Python build that crashes at runtime.

For Linux targets, this extra dependency is unnecessary, but should
not cause other problems ($(LDLIBRARY) is set to the same as
$(LIBRARY) if not building any shared library).

This fixes MSYS2 cpython-mingw issue python#162.

When building shared modules (*.pyd) for MinGW, they link against
the import library for the main python (e.g. -lpython3.11). When
linking shared modules on Linux, this doesn't happen, but those
shared libraries are linked with undefined references which
then are fulfilled by the host process when they are loaded.

Add a dependency to make sure that $(LDLIBRARY), e.g.
libpython$(LDVERSION).dll.a, exists before starting to build
the shared modules.

Previously, if libpython$(LDVERSION).dll.a didn't exist when
the shared modules were linked, some of them failed to link,
but this wasn't reported as an error in the build, and a
later invocation of setup.py would retry building them, which
then would succeed. E.g. there was a seemingly benign race
condition in the build.

However, in some rare cases, the race condition no longer
was benign. The build also produces a corresponding static library,
$(LIBRARY), e.g. libpython$(VERSION)$(ABIFLAGS).a - which in
the end would be named similarly, libpython3.11.a, when
$(LDLIBRARY) would be libpython3.11.dll.a.

If the static library exists but the import library doesn't, then
most modules would still fail to link, but a few ones wouldn't
(select, _multiprocessing, _overlapped and _socket). The ones
that did succeed linking with the static library would crash at
runtime though.

By making sure that the right, intended library to fulfill the
linker parameter "-lpython3.11" exists before building the shared
modules, we avoid the whole race condition that in some rare
cases could produce a Python build that crashes at runtime.

For Linux targets, this extra dependency is unnecessary, but should
not cause other problems ($(LDLIBRARY) is set to the same as
$(LIBRARY) if not building any shared library).

This fixes MSYS2 cpython-mingw issue python#162.