This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Cpython "pystate.h" subdirectory wrong
Type: compile error Stage: resolved
Components: C API Versions: Python 3.8
Status: closed Resolution: duplicate
Dependencies: Superseder: Include/cpython/pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure
View: 39026
Assigned To: Nosy List: andrewtomazos, eric.smith, jpelizza, vstinner, xry111
Priority: normal Keywords: patch

Created on 2020-05-16 07:40 by jpelizza, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 24744 closed xry111, 2021-03-04 10:29
Messages (10)
msg369019 - (view) Author: (jpelizza) Date: 2020-05-16 07:40
Line 9 of pystate.h is:
#include "cpython/initconfig.h"
should be:
#include "./initconfig.h"
since pystate.h is already inside cpython dir.
msg369051 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2020-05-16 15:11
Won't either one work, since "Include" is in the "search path"? Is this causing an actual problem? You have this marked as "compile error", but haven't shown any information about the error, such as what compiler, how it's being invoked, and what the error message is. We need some more information.

If this were to be changed (which I'm not advocating unless there's a real problem), would it be better as "initconfig.h" or "./initconfig.h"? I think they're equivalent.
msg369427 - (view) Author: (jpelizza) Date: 2020-05-20 07:46
In hindsight I provided absolutely nothing, new to this, bound to make dumb mistakes.

Compiler error:

In file included from /usr/include/python3.8/pystate.h:129,
                 from /usr/include/python3.8/genobject.h:11,
                 from /usr/include/python3.8/Python.h:121,
                 from cpppython.cpp:2:
/usr/include/python3.8/cpython/pystate.h:9:10: fatal error: cpython/initconfig.h: No such file or directory
    9 | #include "cpython/initconfig.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Compiler version:
gcc version 9.3.0 (Arch Linux 9.3.0-1)

About the change, yeah "initconfig.h" and the other one are the same, if it is a real problem then there is no need for "./"

After changing it to just "initconfig.h" the code compiled normally. From my understanding since initconfig.h is already inside the folder cpython using "cpython/initconfig.h" will try to look for another cpython folder inside the cpython folder and then look for initconfig thus the error.
msg369445 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2020-05-20 11:49
Thanks for the info.

It's weird that this is just showing up for you, and I assume works everywhere else. How are you invoking the compiler, via make, or something else?

And, what's the gcc command line look like when this specific file fails?

I grepped the source code, and didn't see anywhere else where we import something this way, so maybe that's a reason to change it.

As for the "./" think: maybe using it would be a better hint as to what's going on.

But I'd like to hear from other core devs and get their opinion on any change, first.
msg387710 - (view) Author: Andrew Tomazos (andrewtomazos) Date: 2021-02-26 08:11
The problem occurs if you:

   #include <python3.8/Python.h>

on *nix systems.  Note `/usr/include/` is in the system include path.  One workaround is to `-I/usr/include/python3.8` and then `#include <Python.h>`.  Another workaround is to comment out:

   // #include "cpython/initconfig.h"

in `cpython/pystate.h`.

A fix would be appreciated, so that `#include <python3.8/Python.h>` would work out of the box (without having to add `-I`).
msg387711 - (view) Author: Andrew Tomazos (andrewtomazos) Date: 2021-02-26 08:14
msg387713 - (view) Author: Andrew Tomazos (andrewtomazos) Date: 2021-02-26 08:46
After studying the include directives in the Include folder, I think the best fix would be:

In Include/cpython/state.h:

    - #include "cpython/initconfig.h"
    + #include "initconfig.h"

this will mean that state.h will find initconfig.h using a file-relative include (as all the other include directives do), instead of relying on the installed Include directory being put in the header search path.

As this include directive is the only one with this property, the benefit of this change would be that the Include folder would be able to be installed in any subdirectory of a search path, rather than requiring its own dedicated one.

This would mean (for example) you could install different versions of the Python headers side by side and then select between them using preprocessor directives - rather than having to switch up global compiler options.
msg391531 - (view) Author: Xi Ruoyao (xry111) * Date: 2021-04-21 17:20
Dup of #39026.  And the proposed fix is nack'ed in #39026.
msg402829 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-09-29 08:20
Having two header files with the same name in two directories which are part of the include directories is causing issues like this one :-(

For the internal C API, I solve the issue by adding "pycore_" prefix to filenames.

Maybe pystate.h should be renamed to cpython_pystate.h to avoid to fix the issue. It would include cpython_initconfig.h.
msg402836 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2021-09-29 09:27
I mark this issue as a duplicate of bpo-39026.
Date User Action Args
2022-04-11 14:59:31adminsetgithub: 84822
2021-09-29 09:27:52vstinnersetstatus: open -> closed
superseder: Include/cpython/pystate.h contains non-relative of initconfig.h include causing macOS Framework include failure
messages: + msg402836

resolution: duplicate
stage: patch review -> resolved
2021-09-29 08:20:36vstinnersetnosy: + vstinner
messages: + msg402829
2021-04-21 17:20:33xry111setmessages: + msg391531
2021-03-04 10:29:36xry111setkeywords: + patch
nosy: + xry111

pull_requests: + pull_request23514
stage: patch review
2021-02-26 08:46:27andrewtomazossetmessages: + msg387713
2021-02-26 08:14:13andrewtomazossetmessages: + msg387711
2021-02-26 08:11:19andrewtomazossetnosy: + andrewtomazos
messages: + msg387710
2020-05-20 11:49:15eric.smithsetmessages: + msg369445
2020-05-20 07:46:23jpelizzasetmessages: + msg369427
2020-05-16 15:11:36eric.smithsetnosy: + eric.smith
messages: + msg369051
2020-05-16 07:40:57jpelizzacreate