classification
Title: timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH
Type: compile error Stage:
Components: Build, Extension Modules Versions: Python 3.6, Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Ilya.Kulakov, nascheme, r.david.murray, steve.dower, tnmurphy, vstinner
Priority: normal Keywords:

Created on 2015-07-06 13:13 by tnmurphy, last changed 2018-06-28 19:18 by nascheme.

Messages (10)
msg246358 - (view) Author: Timothy Murphy (tnmurphy) Date: 2015-07-06 13:13
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 

Output:
/home/tim/build/cpython/Modules/timemodule.c: In function ‘time_strftime’:
/home/tim/build/cpython/Modules/timemodule.c:656:9: error: unknown type name ‘_Py_BEGIN_SUPPRESS_IPH’
         _Py_BEGIN_SUPPRESS_IPH
         ^
/home/tim/build/cpython/Modules/timemodule.c:656:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
/home/tim/build/cpython/Modules/timemodule.c:658:9: error: ‘_Py_END_SUPPRESS_IPH’ undeclared (first use in this function)
         _Py_END_SUPPRESS_IPH
         ^
/home/tim/build/cpython/Modules/timemodule.c:658:9: note: each undeclared identifier is reported only once for each function it appears in
/home/tim/build/cpython/Modules/timemodule.c:662:9: error: expected ‘;’ before ‘if’
         if (buflen > 0 || i >= 256 * fmtlen) {
         ^
/home/tim/build/cpython/Modules/timemodule.c:657:9: warning: unused variable ‘buflen’ [-Wunused-variable]
         buflen = format_time(outbuf, i, fmt, &buf);
         ^
/home/tim/build/cpython/Modules/timemodule.c:561:20: warning: unused variable ‘buflen’ [-Wunused-variable]
     size_t fmtlen, buflen;
                    ^
/home/tim/build/cpython/Modules/timemodule.c:561:12: warning: variable ‘fmtlen’ set but not used [-Wunused-but-set-variable]
     size_t fmtlen, buflen;
            ^
cc1: some warnings being treated as errors

Failed to build these modules:
time
msg246359 - (view) Author: Timothy Murphy (tnmurphy) Date: 2015-07-06 13:17
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. 

diff -r 5adf995d443f Modules/timemodule.c
--- a/Modules/timemodule.c	Mon Jul 06 14:03:01 2015 +0300
+++ b/Modules/timemodule.c	Mon Jul 06 14:15:52 2015 +0100
@@ -30,6 +30,13 @@
 #endif /* MS_WINDOWS */
 #endif /* !__WATCOMC__ || __QNX__ */
 
+#define Py_BUILD_CORE 
+#include "pyport.h"
+
+#define _Py_BEGIN_SUPPRESS_IPH
+#define _Py_END_SUPPRESS_IPH
+
+
 /* Forward declarations */
 static int pysleep(_PyTime_t);
 static PyObject* floattime(_Py_clock_info_t *info);
msg246365 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-07-06 14:43
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.
msg246367 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-07-06 14:52
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.
msg246368 - (view) Author: Timothy Murphy (tnmurphy) Date: 2015-07-06 14:57
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 #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.
msg246369 - (view) Author: Timothy Murphy (tnmurphy) Date: 2015-07-06 15:04
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.
msg252763 - (view) Author: Ilya Kulakov (Ilya.Kulakov) * Date: 2015-10-11 05:27
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.
msg252785 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-10-11 08:51
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.
msg252863 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-10-12 15:43
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?
msg320684 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2018-06-28 19:18
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.
History
Date User Action Args
2018-06-28 19:18:41naschemesetnosy: + nascheme
messages: + msg320684
2015-10-12 15:43:07steve.dowersetmessages: + msg252863
2015-10-11 08:51:44vstinnersetnosy: + vstinner
messages: + msg252785
2015-10-11 05:27:40Ilya.Kulakovsetnosy: + Ilya.Kulakov
messages: + msg252763
2015-07-06 15:04:12tnmurphysetmessages: + msg246369
2015-07-06 14:57:58tnmurphysetmessages: + msg246368
2015-07-06 14:52:34steve.dowersetmessages: + msg246367
2015-07-06 14:43:51r.david.murraysetnosy: + r.david.murray, steve.dower

messages: + msg246365
versions: + Python 3.6
2015-07-06 13:17:24tnmurphysetmessages: + msg246359
2015-07-06 13:13:16tnmurphycreate