bpo-21536: On Cygwin, C extensions must be linked with libpython #13549
Conversation
general. It is also possible to link against a library or executable with a statically linked libpython, but not both with the same DLL. In fact building a statically linked python is currently broken on Cygwin for other (related) reasons. The same problem applies to other POSIX-like layers over Windows (MinGW, MSYS) but Python's build system does not seem to attempt to support those platforms at the moment.
| if get_config_var('ANDROID_API_LEVEL') != 0: | ||
| link_libpython = True | ||
| elif get_config_var('MACHDEP') == 'cygwin': | ||
| link_libpython = True |
There was a problem hiding this comment.
Here I just mostly "unwrapped" the single if condition above into multiple explicit branches, which I think makes the logic clearer, especially with more cases added on...
|
LGTM.I merged your PR, thanks! |
|
Thank you, though perhaps it was too quick! There is a bug in my logic in configure.ac. |
Ah? I didn't notice. Write a second PR in that case ;-) |
|
|
||
| if test -z "$ANDROID_API_LEVEL"; then | ||
| if test -z "$ANDROID_API_LEVEL" -o "$MACHDEP" != "cygwin"; then |
There was a problem hiding this comment.
This should be -a not -o technically, but it would probably be even clearer if the test weren't negated, and were instead
if test -n "$ANDROID_API_LEVEL" -o "$MACHDEP" = "cygwin";
There was a problem hiding this comment.
"even clearer if the test weren't negated" yeah, please invert the test conditions to avoid double negation ;-)
There was a problem hiding this comment.
Glad we're on the same page. It's the double-negation that tripped me up in the first place, and probably you too.
|
Hum, is I'm not comfortable with double negation :-) Maybe write: |
…honGH-13549) It is also possible to link against a library or executable with a statically linked libpython, but not both with the same DLL. In fact building a statically linked python is currently broken on Cygwin for other (related) reasons. The same problem applies to other POSIX-like layers over Windows (MinGW, MSYS) but Python's build system does not seem to attempt to support those platforms at the moment.
| # remain RTLD_LOCAL and so the shared libraries must be linked with | ||
| # libpython when python is built with a shared python library (issue | ||
| # bpo-21536). | ||
| # On Cygwin (and if required, other POSIX-like platforms based on | ||
| # Windows like MinGW) it is simply necessary that all symbols in | ||
| # shared libraries are resolved at link time. |
There was a problem hiding this comment.
@embray trying to better understand this change...
On Android, before this PR, it is technically possible to refrain from linking to libpython if and only if python itself is configured as a static build.
This Cygwin change applies here also within if get_config_var('Py_ENABLE_SHARED'): -- does Cygwin only need libpython in shared builds, like Cygwin, or all the time, like MSVC?
The commit message glosses over it by pointing out that static Cygwin builds are broken anyway. I am simply curious what the most correct approach is (when implementing similar logic outside of distutils).
It is also possible to link against a library or executable with a
statically linked libpython, but not both with the same DLL. In fact
building a statically linked python is currently broken on Cygwin
for other (related) reasons.
The same problem applies to other POSIX-like layers over Windows
(MinGW, MSYS) but Python's build system does not seem to attempt
to support those platforms at the moment.
Follow-up to #12946
https://bugs.python.org/issue21536
@vstinner