Repository navigation
timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH #68763
Description
| BPO | 24575 |
|---|---|
| Nosy | @nascheme, @vstinner, @bitdancer, @zooba, @Kentzo |
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:
assignee = None
closed_at = None
created_at = <Date 2015-07-06.13:13:16.444>
labels = ['extension-modules', 'build']
title = 'timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH'
updated_at = <Date 2018-06-28.19:18:41.224>
user = 'https://bugs.python.org/tnmurphy'bugs.python.org fields:
activity = <Date 2018-06-28.19:18:41.224>
actor = 'nascheme'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Build', 'Extension Modules']
creation = <Date 2015-07-06.13:13:16.444>
creator = 'tnmurphy'
dependencies = []
files = []
hgrepos = []
issue_num = 24575
keywords = []
message_count = 10.0
messages = ['246358', '246359', '246365', '246367', '246368', '246369', '252763', '252785', '252863', '320684']
nosy_count = 6.0
nosy_names = ['nascheme', 'vstinner', 'r.david.murray', 'steve.dower', 'Ilya.Kulakov', 'tnmurphy']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue24575'
versions = ['Python 3.5', 'Python 3.6']
Activity
tnmurphy commentedon Jul 6, 2015
My build of the 3.5 head fails in timemodule.c which results in an interpreter that can run but can't "import time".
Details:
changeset 96851:bb9fc884a838
on Fedora Linux x86_64
Failed to build these modules:
time
tnmurphy commentedon Jul 6, 2015
This patch works for me on Linux but it seems clearly wrong for windows.
The problem is that using it on windows introduces a dependency and I don't have a windows machine to check if this is ok. To me it seems that the time module must have been built as part of the core somehow in the past.
bitdancer commentedon Jul 6, 2015
It works for us. I've added Steve Dower to nosy, who I believe added that code. IIUC it should only come into play on Windows.
Are you using a stock checkout, or have you applied local modifications? The changeset id you reference doesn't have IPH in it.
zooba commentedon Jul 6, 2015
Last time this came up the solution was either "hg purge" or "make distclean", I don't remember which worked.
timemodule.c should already be built with Py_BUILD_CORE set in CFLAGS, but apparently it's possible for that setting to disappear from one of the generated build files.
tnmurphy commentedon Jul 6, 2015
I'm so sorry. I apologise for mucking up and giving you the wrong changeset :-(
my hg summary output is as follows:
parent: 96850:5adf995d443f
Issue bpo-18684: Fixed reading out of the buffer in the re module.
branch: 3.5
commit: 2 unknown (clean)
update: (current)
mq: 1 unapplied
I have no modifications.
The macros only have meaningful definitions on windows and they come from ./Include/pyport.h.
I could just include this but they are protected by Py_BUILD_CORE so I'm not clear what's really going on and ... hence I leave it to others.
tnmurphy commentedon Jul 6, 2015
Ok so I see the compiler is including pyport.h (using strace) so that means that it can only be a case of Py_BUILD_CORE not being in CFLAGS for timemodule.o.
I suppose that this is a configure problem. I'll try to work out how/why.
Kentzo commentedon Oct 11, 2015
Why is it important to hide these 2 macroses behind Py_BUILD_CORE?
Certain tools for embedding python may try to compile modules independently. I realize that it's not a problem of Python to take care of that, but in that particular case if hiding these 2 macroses behind Py_BUILD_CORE is not required, it may help to retain compatibility with such tools.
vstinner commentedon Oct 11, 2015
setup.py gets C flags from Makefile using the sysconfig module. You must have -DBUILD_CORE in Makefile. When I compiled Python using "./configure; make" the time module is build.
How do you compile Python?
"#define _Py_BEGIN_SUPPRESS_IPH" is already declared in pyport.h which is included by Python.h, and timemodule.c includes Python.h.
zooba commentedon Oct 12, 2015
If they are compiled independently, they should have Py_BUILD_CORE set.
That flag is meant for the headers, which serve dual purposes, not the module itself. *Any* C file that is part of core should expect that option to be set for when it includes its headers.
All that said, it seems that _datetimemodule.c forces Py_BUILD_CORE on to get access to some extra definitions, which presumably means that somebody at some point wanted to compile it into an extension module. I don't see the use case here though - is there something about its public API that is not stable?
nascheme commentedon Jun 28, 2018
I ran into an error like this and perhaps I have a clue was why some people run into it. Dynamic modules built from Modules/Setup will need to have -DPy_BUILD_CORE defined within the Setup file in the case they need to use the _Py_BEGIN_SUPPRESS_IPH macro.
The Setup file is generated on figure 'configure' but it is not removed if you run "make clean". So, if it gets generated without the Py_BUILD_CORE flags in it, you will get this mysterious build error.
Perhaps Modules/makesetup should be intelligent and add the Py_BUILD_CORE flags as needed. One idea is to check the path of the source code (e.g. timemodule.c) and if the source is within the code interpreter folder, add the BUILD_CORE flag.
Not sure about other platform build systems. It looks like PCbuild does something different as it doesn't use makesetup.
vstinner commentedon Mar 19, 2026
This issue has no activity for 8 years. Python is tested on multiple Fedora machines and I didn't see "error: unknown type name _Py_BEGIN_SUPPRESS_IPH" there. It seems like the issue has been solved in the meanwhile.