-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
BUG: fix compilation of 3rd party modules with Py_LIMITED_API enabled #13725
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
Conversation
@mshabunin - agree we should fix this, but my feeling is that either we just don't use the macros here (this doesn't seem like a critical path, performance-wise) or that we define them if they are not present in, e.g., |
I wonder how we could test the limited API with a CI task. It would need to somehow call all the NumPy C-API functions in order to find the linking errors. |
@mshabunin - given the comment by @mattip, just to be sure I understand the issue here: it is about ensuring we do only use limited API in the header files, correct? You don't really care about what we do inside our own source code. If so, would a possible regression test case be a tiny |
@mhvk , yes it is about header files only. Sure, I'll try to make a test. |
Should we just move |
Makes sense to me - not great to have code in the headers anyway, and it is only used in the |
So, should I move it to sources? Is there any "compile an app with numpy" test exist already? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using the latest NumPy master branch I can reproduce the issue with a 2-line C test file:
#define Py_LIMITED_API
#include "numpy/ndarrayobject.h"
Building will error if the right flags are chosen:
gcc -c test.c $(python3.6-config --includes) -I/python3.6/site-packages/numpy/core/include -Werror=implicit-function-declaration
Removing the first line allows it to build.
Not sure if we'd want to do something like that & build inclusion of headers up from there, but it might spur 8000 suggestions from the NumPy C API gurus in any case.
Since 1.17 is about to be branched, perhaps we should separate the fix from the test (I like @tylerjereddy's super-simple example very much, but it may need some thought about how to actually do the test). For the fix, my suggestion would be to just not use anything from the limited API in our headers. So, for now, just replace the code rather than special-case it. Eventually, we can move the whole thing to a C function, where as @eric-wieser argues correctly, it really belongs. But might as well make that a separate issue. |
Yep, seems fine to me. |
It seems there is consensus that the fix should be non-conditional. @mshabunin could you make this change? |
There are no macros PyTuple_GET_SIZE and PyTuple_GET_ITEM available when compiling with enabled Py_LIMITED_API.
b1e3c09
to
b36f02b
Compare
@mattip , done. |
Perhaps leave the test for another PR or, since tests in CI are difficult to maintain and debug, try something like below
|
c65339e
to
b36f02b
Compare
@mattip , thank you! I'll make a new PR with the test. |
There are no macros
PyTuple_GET_SIZE
andPyTuple_GET_ITEM
available when compiling with enabledPy_LIMITED_API
.Breaking change has been made in PR #10860. Before the change these macros had been used only in
NPY_TITLE_KEY
macro and had not been compiled not used. After the change they have been moved to a function and now are always visible to compiler. Other projects using numpy C-API can not be compiled withPy_LIMITED_API
macro enabled because of this problem.