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
Build failure for 3.6 on Centos 5.11 #72279
Comments
On Centos 5.11, building fails with: Python/dtrace_stubs.o: In function I've tried the usual See also discussion here: https://mail.python.org/pipermail/python-list/2016-September/713888.html |
This is like the OS X Tiger buildbot failure. My stab in the dark is that the compiler (GCC?) being used is interpreting “inline” functions differently to C99. |
(The OS X Tiger buildbot uses a version of GCC 4.0.) |
Benjamin changed PEP-7 to allow static inline functions directly in Python 3.6. But later he added program-wide, linkable inline functions in the Python 3.6 code: 2f77a9f0b9d6: add plain “inline” to header file It seems GCC does not support the C99 syntax for these kind of linkable inline functions until 4.3. Some possible fixes or workarounds:
|
GCC 4.3 was released in March 2008, so I think we are within our rights to drop support for older toolchains. |
This can be related to building manylinux1 binaries where the Centos 5.11 is used. |
Do we know for sure that the manylinux1 builds are affected by this, i.e. can someone try building manylinux1 for 3.6? On the one hand, it is clear that many core developers would like to use these newer features of C, features that have been available for many years. On the other, we may be breaking the "manylinux1" proposed standard and force a move to a newer one, as well as directly impacting some users (such as Steven and one of our buildbots) using old setups. Nick, as BDFL-Delegate for PEP-513, what do you think? We need to resolve this issue before we can release b1. |
While manylinux1 requires that compliant binaries *run* when linked against the GCC 4.2 binaries, the actual recommended compiler version (and the one used in the reference Docker image) is 4.8.2: https://www.python.org/dev/peps/pep-0513/#compilation-of-compliant-wheels That's the compiler version in Red Hat's Developer Toolset 2, the last version to support RHEL/CentOS 5. Unfortunately, softwarecollections.org only goes back to RHEL/CentOS 6, so the devtoolset RPMs are available via Tru Huynh's personal account on the CentOS file server: https://people.centos.org/tru/devtools-2/readme So if 3.6 compiles and runs on CentOS 5 with GCC 4.8.2, that's sufficiently compatible for manylinux1 purposes. |
Thanks for the info, Nick. With that in mind, I"m removing this as a "release blocker" for now. Steven, would it be possible to upgrade gcc on your system? We'll have to deal with the Tiger buildbot separately. |
I created the issue bpo-28099 "Drop Mac OS X Tiger support in Python 3.6. |
Benjamin, what's the rationale behind switching those to inline functions? Does it improve runtime performance or build speed? If not, I don't understand why the additional complexity. |
For the specific case of Dtrace, #define are just fine. But for |
Ned, I know my system is old so I understand if 3.6 no longer supports Shouldn't the build system explicitly report that the compiler is too |
[discussion with Steven about compiler versions taken off-list] |
On Mon, Sep 12, 2016, at 10:34, Łukasz Langa wrote:
Macros for the stub case of dtrace are "fine" because they're so simple. Many of CPython's uglier macros could be replaced by inline funtions. |
For replacing macros, I think “static inline” may be fine, even with older compilers. Maybe these PyDTrace_ functions could also be static inline, since they were originally macros. Or do they really need to be linkable inline functions? |
Don't want to add too much noise, but this issue also affects the manylinux project build compiler (gcc 4.8.2). |
Would it be possible to upgrade the "manylinux" compiler (take a more recent GCC version)? |
No, it's possible :-(. 4.8.2 is the very most modern version of GCC you can use if you want to build binaries to run on CentOS/RHEL 5. (And "binaries should run on CentOS/RHEL 5" is the definition of manylinux1.) I am a bit confused that gcc 4.8.2 is having trouble with cpython 3.6.0b2, though -- supposedly anything newer than gcc 4.3 should be fine with it. And yet. One possibility is that something funny is going on inside the build scripts Robin's using and that Python's ./configure is somehow finding and using the platform compiler (gcc 4.1) even though the first "gcc" in $PATH is 4.8.2, which would make this a false alarm. |
I executed gcc --version (&cc --version) in the do_cpython_build function immediately prior to the make -j2 that builds python noth show 4.8.2. I see the exact same errors as in the initial report. If the makefile or the configure is doing something special then I guess I have to work around that. A possibility is that the CFLAGS="-Wformat" in the environment or the configure argument --disable-shared is having some effect. I have made very few changes to the build scripts. |
@rgbecker: Are you able to pull out the config.log generated by running python's ./configure script, and post that somewhere? |
"Don't want to add too much noise, but this issue also affects the manylinux project build compiler (gcc 4.8.2)." Can you elaborate on these issues? Are you getting the same errors than the error described in the initial message with GCC 4.2? If not, you may open a new issue to track compilation issues of Python 3.6 on GCC 4.8. |
Hi njs, my manylinux diffs full output of the docker command https://www.reportlab.com/media/manylinux-docker-run-output.txt the end showing the 3.6b2 config and the failure |
Please check if you have enabled the compiler as default by enabling the devtoolset on CentOS 5. I have compiled Python 3.6b2 on Ubuntu 14.04 with gcc 4.8.4 without any problems. Also keep in mind the default gcc for CentOS 5 will fail because it is to old. |
Also verified on CentOS 6.8 with devtoolset2 installed, gcc 4.8.2 |
tds333, the config says that 4.8.2 is being used, configure:3902: gcc --version >&5 but perhaps the make is doing something else or the build goes wrong because shared is disabled. |
Yeah, the config.log there clearly shows that configure is using gcc 4.8.2 on the failed builds. Very odd. Stepping back for a moment, is there any point in continuing to debug this? Given Benjamin's comment up-thread:
My impression is that restricting inline functions to 'static inline' only is the best plan for 3.6 anyway, since AFAIK that really does work on all the compilers that people are likely to run into, while non-static inline has problems with the default compilers on both CentOS 5 and OS X. |
"while non-static inline has problems with the default compilers on both CentOS 5 and OS X." The changes introduced in 3.6 prevent compilation with gcc4.0 which was the default Apple-supplied compiler on Mac OS X 10.4 (Tiger). 3.6 currently compiles correctly with gcc4.2, the default on Mac OS X 10.5 (Leopard). |
So to summarize our current understanding: gcc 4.3 added support for C99 inline, which explains why gcc 4.2 works and gcc 4.8 doesn't. WTF is going on. |
Any different results with CFLAGS="-fno-gnu89-inline"? |
I'm not able to access my work computer, I'll try later today at home. |
benjamin.peterson: I tried adding that option -fno-gnu89-inline conditionally for the 3.6.0b2 build, but it goes wrong in config with an error configure:3913: $? = 4 The full docker output is here https://www.reportlab.com/media/manylinux-docker-run-output-2.txt |
After some searching I tried adding -std=gnu99 and the config goes through OK, but running make produces [root@d3cce9786c2e Python-3.6.0b2]# make -j2 |
for what it's worth I tried reverse patching https://hg.python.org/cpython/rev/63ae310b60ff/ and https://hg.python.org/cpython/rev/2f77a9f0b9d6/ in the manylinux docker and the make then proceeds fine with one warning at the end *** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-x86_64-3.6/_sqlite3.cpython-36m-x86_64-linux-gnu.so: undefined symbol: sqlite3_stmt_readonly Following modules built successfully but were removed because they could not be imported: |
"*** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-x86_64-3.6/_sqlite3.cpython-36m-x86_64-linux-gnu.so: undefined symbol: sqlite3_stmt_readonly" That's a different issue: most likely you are building with an old version of libsqlite3. See, for example: ghaering/pysqlite#85 |
New changeset fd9a4bd16587 by Benjamin Peterson in branch '3.6': |
I changed the dtrace stubs to static inline. Probably should reopen an investigation for 3.7. I would like to have exportable inlines. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: