Closed as not planned
Closed as not planned
Copy link
Labels
Description
Bug report
Bug description:
Including Python.h on <3.13 from a .cpp file results in the following:
In file included from include/python3.11/Python.h:50:
include/python3.11/bytesobject.h:10:1: error: import of C++ module 'Darwin.C.stdarg' appears within extern "C" language linkage specification [-Wmodule-import-in-extern-c]
You can work around this on a per project basis with -Wno-module-import-in-extern-c, but that's still pretty annoying.
This is due to an include of a system header from inside an extern "C" block, which LLVM doesn't seem to like anymore with default flags on macOS.
I believe the changes related to #108769 will fix this. Can we get them backported?
CPython versions tested on:
3.11, 3.12
Operating systems tested on:
macOS
Activity
vstinner commentedon Oct 31, 2023
What is your clang version?
ronaldoussoren commentedon Nov 5, 2023
Also, please add a minimal example on how to reproduce the issue.
FWIW, I tried to reproduce using the following trivial code as a c++ file (.cc suffix):
This worked fine when building with "cc -c repro.cc" using the clang included with the current Xcode 15.1 beta.
Version Details
Xcode:
Clang:
lunixbochs commentedon Nov 10, 2023
This triggers it for me:
cc `python3.11-config --includes` -fmodules -fcxx-modules test.cppvstinner commentedon Nov 10, 2023
Can you provide the minimum test.cpp file reproducing the issue?
ronaldoussoren commentedon Nov 10, 2023
The two-line file in my previous comment is enough to reproduce the issue (with 3.9 or later)
The error goes away if I add
-Wno-module-import-in-extern-cto the compiler arguments, but that's almost certainly not the right fix (and I haven't tried building an extension with modules enabled and this flag to suppress the error).Actually avoiding the error requires non-trivial reorganisation of our header files to ensure that all includes of system headers are done outside of
extern "C"blocks.lunixbochs commentedon Nov 10, 2023
It looks like these changes for 3.13 already have the correct reorganization, they'd just need to be backported: #108769
ronaldoussoren commentedon Dec 8, 2023
@vstinner : Are the changes in #108769 something that can be back ported to 3.11 and 3.12? I'm worried that moving includes around can affect 3th-party extensions.
Alternatively we can document that Python 3.12 and earlier don't support building with C++ modules enabled, and add a test based on my earlier message to 3.13 to ensure that building with modules continues working there.
vstinner commentedon Feb 7, 2024
I reproduced a similar error using a manually created C++20 module.
Work in the
Lib/test/test_cppext/directory.Create
Lib/test/test_cppext/mymodule.cppm:Create
Lib/test/test_cppext/Makefile:Pre-compile
mymodule.cppmusing theMakefileinLib/test/test_cppext/:Modify
Lib/test/test_cppext/extension.cpp, before#include "Python.h", add:Build the C++ extension with:
Building the C++ extension fails with:
What I understood:
import ...if built with C++.<Python.h>includes some system header files insideextern "C" { ... }. In this case, building<Python.h>with C++20 modules fails with an error.In short:
#include ...must not be done insideextern "C" { ... }.#include ...can be indirect, header A can include header B which includes a system header.Python.hmakes it easier sincePython.hdoesn't useextern "C" { ... }.vstinner commentedon Feb 7, 2024
The problem also exists for the internal C API: see #115105.
vstinner commentedon Jan 27, 2025
Since only Python 3.12 is impacted (Python 3.11 no longer gets bugfixes) and the lack of activity for one year, I suggest closing this old issue as "WONT FIX".
vstinner commentedon Feb 27, 2025
This issue has been fixed in Python 3.13.