New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cygwin build broken due to use of &PyType_Type in static declaration in _abc module #78392
Comments
This is essentially the same as bpo-21124, but introduced more recently with the addition of the _abc_data_type in the _abc module. The workaround is simply to use PyVarObject_HEAD_INIT(NULL, 0) instead of PyVarObject_HEAD_INIT(&PyType_Type, 0); PyType_Ready should take care of the rest. P.S. I'm trying to get going again on the project of adding an AppVeyor build, and eventually a buildbot for Cygwin. My previous attempt was doomed because I wanted to fix all failing tests on Cygwin *first*. This time I am going for a more "instant gratification" approach of just skipping the tests that fail (for now) so that I can at least catch new regressions, and then gradually re-enabled skipped tests as I can find fixes for them. However, for that to happen we at least need a minimal build to work. |
For those who are not very aware of Cygwin issues: what is wrong with PyVarObject_HEAD_INIT(&PyType_Type, 0); |
I'm glad you asked, because it actually got me thinking, and since I added a fix (albeit an unsatisfying one) for bpo-34212, this fix is no longer strictly necessary *so long as* the _abc module is always built as a core built-in (that is, linked into libpython). IIUC that is the case since _abc is required for the core, but I'm not sure. The problem is explained somewhat in bpo-21124, but what it comes down to is that if the linker can't resolve PyType_Type at link time it will make a complaint like "can't initialize global with a non-constant". Because of bpo-34212, when compiling _abc.c it was using the wrong external linkage for PyType_Type (treating it as some data that needs to be imported from an other DLL, rather than data in the same DLL). But with a fix for bpo-34212 this is not a problem (again, so long as the _abc module is included in libpython). |
Linker issues are always tricky... I understand that there is no problem within libpython, so the questions below refer to extension modules. I am asking them from the point of view of somebody writing Python extension modules who is clueless about Cygwin. So you're saying that it's not allowed to refer to &PyType_Type in a static struct? But it is OK to refer to &PyType_Type in code? I assume that there is nothing special about PyType_Type and that this apply for all variables. Are functions OK? For example, in functools.c I see static PyGetSetDef partial_getsetlist[] = { What makes functions different from variables? Aren't they essentially just pointers? |
You're on the right track by noting a difference between functions and data variables. I can tell you off the bat that when it comes to data imported from DLLs, non-functions are handled (somewhat by necessity) quite differently from functions. That said, since you asked, I struggled to articulate *exactly* why this exact problem occurs on Cygwin (actually on Windows in general), so I thought about it for a while and wrote up an explanation in a blog post: http://iguananaut.net/blog/programming/windows-data-import.html The TL;DR though is that limitations of how the runtime dynamic loader on Windows works are such that it's impossible to initialize static data with a pointer to some data in an external library. The compiler knows this and prevents you from doing it. The workaround is simple enough for most cases: Complete the initialization at runtime. In the case of PyType_Type objects, PyType_Ready can set their base type at runtime just fine. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: