Issue 13241: llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7) (original) (raw)
Created on 2011-10-21 19:49 by Oleg.Plakhotnyuk, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (49)
Author: Oleg Plakhotnyuk (Oleg.Plakhotnyuk) *
Date: 2011-10-21 19:49
Trying to build latest development revision:
localhost:repo family$ hg summary parent: 73044:a985d733b3a3 tip #12753: Add support for Unicode name aliases and named sequences. branch: default commit: (clean) update: (current)
Constantly getting this error:
./python.exe -SE -m sysconfig --generate-posix-vars Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Assertion failed: (compact->utf8_length == 0), function _PyUnicode_CheckConsistency, file Objects/unicodeobject.c, line 399. make: *** [sysconfig] Abort trap
However, tag v3.2.2 seems to build successfully.
OS: Mac OS X 10.6.8 GCC: 4.2.1
If you have troubles reproducing this issue, feel free to ask any information I can provide that can help.
Thank you in advance!
Author: Oleg Plakhotnyuk (Oleg.Plakhotnyuk) *
Date: 2011-10-21 19:52
Oh yes. I am building with this command line: ./configure --with-pydebug && make -j2
Author: STINNER Victor (vstinner) * 
Date: 2011-10-21 19:53
It is a compiler bug in GCC 4.2.1 with -O3. Try to compile attached unicode.c program with gcc -O3. The correct result is:
$ gcc -O3 unicode.c -o unicode && ./unicode is ascii? 0 is compact? 1 is compact ascii? 0 _PyUnicode_COMPACT_DATA: 88 vs 88 PyUnicode_DATA: 88 vs 88 explicit cast: 88 vs 88
With gcc 4.2.1 and -O3, you get "is compact ascii? 1".
Author: STINNER Victor (vstinner) *
Date: 2011-10-21 19:54
The bug has been fixed in GCC, try a more recent version using ./configure CC=gccX.Y.
Author: Ezio Melotti (ezio.melotti) *
Date: 2011-10-21 19:55
It should also work without --with-pydebug, or with a different compiler.
Author: Ned Deily (ned.deily) *
Date: 2011-10-21 21:33
I believe this was a bug specific to the llvm-gcc compiler shipped with Xcode 4.1 and possibly Xcode 4.0. I do not have Xcode 4 on OS X 10.6 but haypo's test does fail with the llvm-gcc 4.2.1 that comes with Xcode 4.1 on 10.7. Can you confirm exactly which compiler you are using, i.e. the complete --version output from the compiler used in your python build? If you have not installed Xcode 4.2, one solution is to use CC=gcc-4.2 which uses the plain gcc-4.2, not llvm-gcc-4.2. For 10.6, I recommend sticking with Xcode 3 if at all possible for the time being.
Author: Ezio Melotti (ezio.melotti) *
Date: 2011-10-21 21:35
See also http://mail.python.org/pipermail/python-dev/2011-September/113731.html
Author: Oleg Plakhotnyuk (Oleg.Plakhotnyuk) *
Date: 2011-10-23 10:33
Thank you all for help. I finally managed to build it. :-) So here are complete steps I've taken to build python after OS reinstall:
- Install XCode 4.2
- Install MacPorts
- sudo port -v selfupdate
- sudo port install gcc46
- ./configure CC=gcc-mp-4.6 LDFLAGS=-L/opt/local/lib --with-pydebug && make -j2
Should I post this somewhere for others who may face similar problems?
Author: Ned Deily (ned.deily) *
Date: 2011-10-23 16:17
In general, I would not recommend using anything other than an Apple-supplied tool chain for building anything on Mac OS X. To help us better understand the issues, can you say exactly which compilers you tried originally, i.e. the complete --version output from the compiler(s) used in your failing Python builds?
Because of the current somewhat chaotic OS X compiler situation, I am in the process of performing a controlled test of building and testing various current versions of Python with the available Xcode compilers for 10.7 and 10.6.
Author: Oleg Plakhotnyuk (Oleg.Plakhotnyuk) *
Date: 2011-10-23 17:06
Ah, of course. Initially I've tried to compile using this:
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
XCode version 4.2, build 4C199
Author: STINNER Victor (vstinner) *
Date: 2011-10-23 18:35
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
Oh, that's not GCC but llvm-gcc. It is maybe a bug in LLVM?
Author: Ned Deily (ned.deily) *
Date: 2011-10-24 06:30
Oleg, thanks. That is consistent with previous reports; so far, this issue has only been reported with llvm-gcc, not the plain gcc-4.2's shipped in Xcode prior to 4.2.
Author: STINNER Victor (vstinner) *
Date: 2011-10-26 11:52
I asked for more information about llvm-gcc on IRC (#llvm). Extracts:
- "llvm-gcc is not maintained." ("Clang and DragonEgg are.) "Apple is the maintainer of Apple's version of llvm-gcc and clang."
- "Apple ships a [llvm-gcc] branch at a random point in svn + some bug fixes, not a proper release."
- "llvm-gcc is Apple's GCC (which was never sync'd with mainline past 4.2.1 because the FSF changed the license) with LLVM on the back end."
- llvm-gcc-4.5 in Ubuntu 10.10 is not llvm-gcc, it's dragonegg, a new project
If I understood correctly, llvm-gcc is only the default C compiler of Xcode 4.1. I don't think that you should workaround llvm-gcc bugs. If you are using Xcode 4.1, you can compile Python with clang. clang is a different C compiler and it doesn't have the bug.
Author: Ned Deily (ned.deily) *
Date: 2011-10-26 16:40
Haypo, the OP has a workaround. IMO, we should not be making any recommendations about which Apple compiler to use on OS X 10.7 until we have completed test cycles of each. There are too many variables at the moment. I am doing that and should have results in a few days.
Author: Julian Berman (Julian) *
Date: 2011-10-27 20:24
I was unsuccessful building tip with any of the 3 compilers. Full paste of output from ./configure and make, along with haypo's test file are attached.
http://paste.pound-python.org/show/14320/
I'm on 10.7.2, XCode is 4.1 (compiler versions in the paste).
Upgrading to XCode 4.2 is undesirable, since it removes vanilla gcc. Myself and a few others are avoiding upgrading until homebrew adds vanilla gcc and / or Apple gets things fully sorted, so, being able to build with this would be nice.
Author: Ned Deily (ned.deily) *
Date: 2011-10-27 21:12
Julian, I am able to build and run the current default (3.3) tip (52b35dae22d1) on 10.7.2 with the gcc-4.2 from Xcode 4.1, with or without debug enabled. Are you sure you have pulled all the latest updates and are using a clean build directory? If so, please open a new issue showing the details and the exact ./configure command used.
Author: Julian Berman (Julian) *
Date: 2011-10-27 21:58
Never mind, yes, you're correct, somehow my build dir must have been dirty.
Sorry bout that.
Author: Lucas Sinclair (xapple)
Date: 2011-11-04 14:42
I'm on 10.7.2, with XCode is 4.2 and the problem is still present. The command "ggc -v" produces the following output:
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
The command "./configure --with-pydebug && make -j2" fails with the following output:
Assertion failed: (compact->utf8_length == 0), function _PyUnicode_CheckConsistency, file Objects/unicodeobject.c, line 381. make: *** [sysconfig] Abort trap: 6
The only solution seems to be to install macports and use it to get a more recent gcc like Oleg Plakhotnyuk suggested.
Author: Ned Deily (ned.deily) *
Date: 2011-11-04 16:37
Lucas, exactly what source version of Python are you trying to build (i.e what does "hg summary" say)?
Author: Lucas Sinclair (xapple)
Date: 2011-11-04 17:17
I just cloned cpython today. The output of "hg summary" is:
parent: 73351:2bec7c452b39 tip Fix C89 incompatibility. branch: default commit: (clean) update: (current)
Author: Michael Foord (michael.foord) *
Date: 2011-11-07 23:19
On OS X Lion, with XCode 4.2 installed, I find the following works (no need to install macports):
./configure CC=gcc-4.2 --prefix=/dev/null --with-pydebug
Author: Michael Foord (michael.foord) *
Date: 2011-11-07 23:35
Ah, it seems I have XCode 3.2.6 installed alongside XCode 4.2.
Author: Lucas Sinclair (xapple)
Date: 2011-11-08 07:50
Well the configure parameters suggested by Michael Foord worked. I was able to build cpython on a mac. But I could not have guessed how to make it work.
Shouldn't these instructions be added here http://docs.python.org/devguide/ ?
Shouldn't the latest version of OS X be included in the list of *nix systems that cpython is checked to build on ?
Author: Ned Deily (ned.deily) *
Date: 2011-11-08 08:46
Lucas, there is nothing particularly special about the configuration parameters that Michael used other than enabling debug. Prior to Xcode 4, Xcode supplied a "standard" (non-LLVM) gcc as the default compiler, 4.2 for 10.6 and 4.0 for 10.5 and 10.4. Python is regularly built and supported on these configurations and is known to work using a default ./configure (with no parameters). Xcode 4.2 is problematic because it no longer includes the non-LLVM gcc and there have been various rumors of problems and at least one patch applied already. As noted above, I am testing the various significant configure and compiler options right now for Xcode 4.2 and will update this issue with recommendations and patches (if necessary) when that is complete.
Author: Michael Foord (michael.foord) *
Date: 2011-11-20 00:57
Note that this works for me on a Macbook Air that has never had Snow Leopard, nor XCode 3 installed.
As far as I can tell non-llvm gcc is installed by XCode 4.2: /usr/bin/gcc-4.2
Author: Ronald Oussoren (ronaldoussoren) *
Date: 2011-12-13 22:00
The bug in the 'gcc' command is still present when using Xcode 4.2.1 (that is, the attached unicode.c miscompiles with "gcc -O3").
Clang (again from Xcode 4.2.1) compiles the file correctly, but fails to do a proper build the last few lines of the build log:
clang -bundle -undefined dynamic_lookup build/temp.macosx-10.4-x86_64-3.3/Users/ronald/Projects/python/rw/cpython/Modules/_cursesmodule.o -L/usr/local/lib -lncurses -o build/lib.macosx-10.4-x86_64-3.3/_curses.so /bin/sh: line 1: 84213 Segmentation fault: 11 CC='clang' LDSHARED='clang -bundle -undefined dynamic_lookup ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./setup.py build make: *** [sharedmods] Error 139
The last bit of a gdb stack trace:
#0 0x00007fff86cd94f0 in strlen () #1 0x000000010005bee1 in PyUnicode_FromString (u=0x4c <Address 0x4c out of bounds>) at unicodeobject.c:1735 #2 0x000000010003bb65 in PyDict_GetItemString (v=0x10075cc58, key=<value temporarily unavailable, due to optimizations>) at dictobject.c:2187 #3 0x000000010004eaf8 in add_getset [inlined] () at /Users/ronald/Projects/python/rw/cpython/Objects/typeobject.c:3771 #4 0x000000010004eaf8 in PyType_Ready (type=0x10159efb8) at typeobject.c:4109 #5 0x000000010159209a in PyInit__curses () at /Users/ronald/Projects/python/rw/cpython/Modules/_cursesmodule.c:3293 #6 0x00000001000c0e20 in _PyImport_LoadDynamicModule (name=0x1010f9f80, path=0x10074c750, fp=<value temporarily unavailable, due to optimizations>) at importdl.c:85 #7 0x00000001000beca0 in imp_load_dynamic (self=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at import.c:3804 #8 0x000000010009f0c8 in call_function [inlined] () at /Users/ronald/Projects/python/rw/cpython/Python/ceval.c:4003
For some reason a clean rebuild got a failure in another location, this time in the Py_XDECREF call on line 2966 in ceval.c:
while (!EMPTY()) {
v = POP();
Py_XDECREF(v);
}Due to the optimization level I couldn't get more information.
When I patch the Makefile to use '-O2' instead of '-O3' in CFLAGS the problems stays (obviously with full rebuild).
Patching the optimization level down to '-O1' gives a slightly better result, this time I get:
./python.exe -SE -m sysconfig --generate-posix-vars Fatal Python error: Py_Initialize: unable to load the file system codec SystemError: NULL result without error in PyObject_Call
BTW. I tried to build with srcdir==builddir and "./configure CC=clang" on an up-to-date OSX 10.7 system with Xcode 4.2.1.
Summary of compiler results:
- gcc-4.2 (i686-apple-darwin11-gcc-4.2.1): unicode.c OK, build OK
- gcc (i686-apple-darwin11-llvm-gcc-4.2): unicode.c fails, build fails
- clang: unicode.c OK, build fails
Author: Nam Nguyen (Nam.Nguyen) *
Date: 2011-12-28 02:47
Here's a minimal test case for #define bug in LLVM GCC.
If the base struct is 8-byte long or smaller, the code runs correctly.
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
======== #include <stdio.h> #include <stdlib.h>
typedef struct { int padding; /* remove this and the sizes will be the same */ int type; int attr; } struct_a;
typedef struct { struct_a base; int junk; } struct_b;
#define BUG(op)
((((struct_a*)(op))->type) ? (void*)((struct_a*)(op) + 1) :
(void*)((struct_b*)(op) + 1))
static void* func(void* op) { if (((struct_a*)(op))->type) { return (void*)((struct_a*)(op) + 1); } return (void*)((struct_b*)(op) + 1); }
int main(int argc, char** argv) { struct_b* b = malloc(sizeof(struct_b) + 2); struct_a* a = (struct_a*)b; char* p; a->type = 0; p = BUG(b); printf("expected: %d, actual: %d, b = %p, p = %p\n", sizeof(struct_b), p - (char*)b, b, p); p = func(b); printf("expected: %d, actual: %d, b = %p, p = %p\n", sizeof(struct_b), p - (char*)b, b, p); return 0; }
$ ./bug expected: 16, actual: 12, b = 0x10d7008b0, p = 0x10d7008bc expected: 16, actual: 16, b = 0x10d7008b0, p = 0x10d7008c0
Author: Guido van Rossum (gvanrossum) *
Date: 2012-01-10 00:34
On my system (Snow Leopard OSX 10.6.8, Xcode 4.1) there are several different versions of gcc available in /usr/bin/. Some are symlinks to others; in particular gcc links to llvm-gccc-4.2. By using "./configure CC=gcc-4.2" I get a working config file. I ran "make clean" to avoid reusing possibly corrupt .o files compiled with the default.
Author: Ned Deily (ned.deily) *
Date: 2012-01-10 01:36
That works for Xcode 4.1, which is now out-of-date. The current releases of Xcode, 4.2.x for 10.7 Lion and optionally for 10.6 Snow Leopard, no longer include gcc-4.2, only llvm-gcc and clang. I am working on completing an extensive set of regression tests for all of the development branches versus the most important set of Xcode/platform options and should have results here later this week.
Author: Ronald Oussoren (ronaldoussoren) *
Date: 2012-01-10 07:17
The version of clang included in Xcode 4.2.1 (the current release) still miscompiles Python 3.3 and both C files included in this issue.
The same is true for the Xcode 4.3 beta.
Python 2.7 seems to work fine with the same compiler, either because we don't trigger the bug or it fails in a more subtle way than crashing.
Has anyone filed a bug with Apple and/or the clang developers?
Author: Ronald Oussoren (ronaldoussoren) *
Date: 2012-01-10 07:44
I've filed an issue in Apple's tracker, #10667893. Filing more issues would be helpful, if more issues in their tracker mention this bug it is more likely to get fixed.
Author: Ronald Oussoren (ronaldoussoren) *
Date: 2012-01-11 21:56
I've found a bug in the curses module that is causing problems:
diff --git a/Modules/_cursesmodule.c b/Modules/_cursesmodule.c --- a/Modules/_cursesmodule.c +++ b/Modules/_cursesmodule.c @@ -2056,7 +2056,8 @@ {"encoding", (getter)PyCursesWindow_get_encoding, (setter)PyCursesWindow_set_encoding,
"the typecode character used to create the array"}
"the typecode character used to create the array"},- {NULL, NULL, NULL, NULL}
};
/* -------------------------------------------------------*/
That is, there is no sentinel in the PyCursesWindow_getsets list. Shouldn't this cause failures on more platforms than just OSX?
With this patch I can build python 3.3 with clang (as included in Xcode 4.2.1).
BTW. clang as included with Xcode 4.2.1 seems to build the attached copy of unicode.c without problems, the gcc command still fails though.
I did run into problems when building outside of the source directory, but that seems to be an unrelated issue.
Author: Nam Nguyen (Nam.Nguyen) *
Date: 2012-01-12 00:08
Ronald's patch does fix the segmentation fault with clang-compiled Python. But this bug report seems to be about LLVM-GCC not compiling correctly.
Author: Ronald Oussoren (ronaldoussoren) *
Date: 2012-01-12 07:03
Both clang and llvm-gcc had problems, the llvm-gcc problem is still there and is caused by a compiler bug. There is nothing we can do about that beyond warning Apple.
It's also pretty clear that llvm-gcc (and gcc in general) is on the way out as the system compiler on OSX. It's therefore unlikely that the compiler bug we ran into will get fixed.
I'm leaning towards adding code to configure that either tests for this issue and refers to documentation in Mac/README (also to be added) when this bug is found, or just switches to clang instead of gcc as the default compiler when a recent version of Xcode is detected (and 'CC' is not set in the environment).
Author: Ned Deily (ned.deily) *
Date: 2012-02-04 16:49
While the full regression testing of all active branches against all of the current compiler versions is in progress, my current (and preliminary) recommendations (despite some test failures):
- for OS X 10.7.x, use the latest released Xcode, currently Xcode 4.2.1, and build with clang and debug:
./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7
- for OS X 10.6.x, if possible, continue to use the last released Xcode 3.2 (3.2.6), which includes Apple gcc-4.2 (/usr/bin/gcc-4.2 not llvm-gcc-4.2)
/usr/bin/gcc-4.2 --version ./configure MACOSX_DEPLOYMENT_TARGET=10.6 or ./configure --with-pydebug MACOSX_DEPLOYMENT_TARGET=10.6
- for OS X 10.6.x with Xcode 4 installed (which does not include Apple gcc-4.2), use the latest Xcode 4.2 for 10.6 and use clang and debug:
./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.6
More results and fixes to follow ...
BTW, the current test failures with clang without pydebug include a
number of ctypes test failures (in ctypes.test.test_cfuncs.CFunctions).
If anyone has time to further investigate those, it would be very
helpful (Issue13370).
Author: Michael Foord (michael.foord) *
Date: 2012-02-22 18:20
Note that apple have made gcc available, as part of command line tools for XCode, freely (free developer registration required though) from:
https://developer.apple.com/downloads/
See:
http://kennethreitz.com/xcode-gcc-and-homebrew.html
Author: Ned Deily (ned.deily) *
Date: 2012-02-22 22:39
Note that apple have made gcc available, as part of command line tools >for XCode, freely (free developer registration required though) from: https://developer.apple.com/downloads See: http://kennethreitz.com/xcode-gcc-and-homebrew.html
No. The new version of Xcode (Xcode 4.3, released last week) referred to in that post does not make gcc-4.2 available again. Like Xcode 4.2, it only includes clang and llvm-gcc; 4.3 includes updated versions of each of the two. gcc-4.2 was removed starting with 4.2 and there is no indication that Apple intends to re-instate it. Besides the compiler updates, Xoode 4.3 has been significantly repackaged, including the ability to download and install its components in smaller sub-packages, instead of the monolithic large downloads of recent past releases. However, Xcode 4.3 has moved the install location of components like the SDKs (which are used by Python universal builds) from /Developer to within the new Xcode application bundle (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer); this change will require additional changes to the Python build and Distutils/packaging infrastructure to support properly. For now, the easiest workaround when installing Xcode 4.3 and removing previous versions is to create a symlink from the app bundle Developer directory above to /Developer. I will be testing the new compiler versions shortly and working on more general support for 4.3.
Author: Trent Nelson (trent) *
Date: 2012-05-06 09:16
Hi Ned,
On a brand new OS X Lion install with the latest XCode (4.3.2) and command line tools*, the following worked:
./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7
That is, everything built cleanly, and all tests ran without failures: 336 tests OK. 2 tests altered the execution environment: test_packaging test_site 26 tests skipped: test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu test_devpoll test_epoll test_gdb test_largefile test_lzma test_msilib test_ossaudiodev test_smtpnet test_socketserver test_startfile test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 3 skips unexpected on darwin: test_lzma test_tk test_ttk_guionly
I presume the aim is to be able to build correctly (on all UNIX platforms) with just ./configure --with-pydebug, right?
How's your configure*-toolchain-fu?
Once we fix this I can add the build slave.
Side bar: note that this was a vanilla 10.6->10.7 install. The XCode 4.3.2 install on 10.7 was the first XCode ever installed on the box; there's no /Developer or any of the old gcc* cruft.
[*]: Went to https://developer.apple.com/downloads/index.action, logged in with my Apple ID, then downloaded 'Commandline Tools for XCode - Late March 2012' -- dmg was 'cltools_lion_latemarch12.dmg'.
Author: Michele Orrù (maker) *
Date: 2012-05-06 09:47
./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7
Works on my machine too.
Author: Ned Deily (ned.deily) *
Date: 2012-05-06 13:29
Trent, yes, now that the Xcode 4 situation has settled down a bit, clang is the compiler of choice for OS X 10.7 with Xcode 4.3 although there are still some open questions. I intend to update configure in the near future for all active branches to provide more appropriate defaults for 10.6 and 10.7 and for universal builds with the various SDK locations.
"Once we fix this I can add the build slave"
I'm missing the context for this. Can't you override with environment variables or on the configure command itself?
Author: Trent Nelson (trent) *
Date: 2012-05-06 17:31
"Once we fix this I can add the build slave"
I'm missing the context for this.
Yeah I uh, ....seemed to have deleted the introductory sentence I wrote that said I was doing some prep work before adding an OS X 10.7 build slave.
Can't you override with environment variables or on the configure command itself?
Are you referring to when I set up the build slave? i.e. tweak the local environment the build slave account runs under so that ./configure --with-pydebug works out of the box?
I don't think that's really a precedent we want to set (having build slave owners hack the local environment to work around build issues).
Author: Tom Pinckney (thomaspinckney3) *
Date: 2012-05-10 15:41
FWIW, clang from Xcode 4.3.2 build 4E2002 w/ command line tools built everything fine for me too (i.e., ./configure CC=clang).
LM-SJN-00377886:cpython tom$ uname -a Darwin LM-SJN-00377886 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
LM-SJN-00377886:cpython tom$ /usr/bin/clang --version Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn) Target: x86_64-apple-darwin11.3.0 Thread model: posix
LM-SJN-00377886:cpython tom$ hg summary parent: 76839:bb30116024ac tip Minor fix for test_multiprocessing branch: default commit: (clean) update: (current)
Author: Hynek Schlawack (hynek) *
Date: 2012-06-01 18:04
Ned, any progress/problems?
I've closed two dupes already in the last few days and we're still in the alphas. We really should get this fixed before beta1 or the tracker will be flooded.
Let me know if you need something. :)
Author: Ned Deily (ned.deily) *
Date: 2012-06-01 18:13
Hynek: Thanks for the offer; I've got it. I'll have a comprehensive update to support the new multiple dev environments for 10.6 and beyond prior to b1 (and for 2.7.x and 3.2.x).
Author: Ronald Oussoren (ronaldoussoren) *
Date: 2012-06-13 21:23
The attached configure.ac is a fragment of a configure script that tries to detect if AC_PROG_CC would pick llvm-gcc when clang is also available and then explicitly picks clang.
This would avoid "python3.3 won't build on OSX 10.7" bug reports.
This is not yet a patch to the real configure file because I'd like to add support for automatically picking the compiler inside Xcode.app when the user has Xcode 4 installed without the unix tools (e.g. on an new OSX 10.7 where the user has installed Xcode from the appstore without further actions).
Author: Ronald Oussoren (ronaldoussoren) *
Date: 2012-06-13 23:57
The attached patch "-configure-version1.txt" implements a number of changes to configure (although only configure.ac is present in the patch)
Autodetect the compiler on OSX, in particular
- detect llvm-gcc and use clang instead
- use clang when gcc cannot be found
- use xcrun to locate clang when it isn't in /usr/bin (no Command Line Tools for Xcode)
Detect the most recent working SDK, falls back to the 10.4u SDK when using an old version of Xcode or even '/' when that SDK isn't present
This patch needs work though:
I have barely tested the patch, configure seems to generate a valid Makefile on OSX 10.7 with the unix tools installed, I haven't tested yet on older OSX versions of without the unix tools installed
Distutils/packaging also need changes: need to detect that the running system has different compiler tools than the build system. This is needed to be able to use the binary installers on python.org on systems with other compiler versions and installed SDKs
Author: Ronald Oussoren (ronaldoussoren) *
Date: 2012-09-04 13:20
The configure script for python 3.3 detects llvm-gcc and automatically selects clang when it is found.
That seems to be the best feasible solution for this issue. I therefore propose to close this issue.
Author: Lucas Sinclair (xapple)
Date: 2012-09-04 14:00
I agree to close the issue. I tried following the steps proposed here:
http://docs.python.org/devguide/
And typed these two commands on a OS X 10.8.1 with XCode and command line tools installed.
$ hg clone http://hg.python.org/cpython. $ run ./configure --with-pydebug && make -j2
Python built perfectly.
Author: Ronald Oussoren (ronaldoussoren) *
Date: 2012-09-05 15:19
I've closed the issue as 'wont fix' because llvm-gcc will miscompile 3.3 due to bugs in that compiler. CPython won't work around that compiler bug (if that's even possible).
The workaround: use clang to compile (and on older OSX releases use a different version of GCC that doesn't use the LLVM backend).
History
Date
User
Action
Args
2022-04-11 14:57:23
admin
set
github: 57450
2012-09-05 15:19:35
ronaldoussoren
set
status: open -> closed
resolution: wont fix
messages: +
stage: test needed -> resolved
2012-09-04 14:00:22
xapple
set
messages: +
2012-09-04 13:20:25
ronaldoussoren
set
messages: +
2012-06-27 11:28:03
Anthony.Kong
set
nosy: + Anthony.Kong
2012-06-16 16:25:36
eric.araujo
set
nosy: + eric.araujo
2012-06-13 23:57:57
ronaldoussoren
set
files: + issue13241-configure-version1.txt
messages: +
2012-06-13 21:23:23
ronaldoussoren
set
files: + configure.ac
messages: +
2012-06-01 18:13:55
ned.deily
set
messages: +
2012-06-01 18:04:10
hynek
set
messages: +
2012-06-01 17:54:27
hynek
link
2012-05-28 11:39:52
hynek
link
2012-05-10 15:41:40
thomaspinckney3
set
nosy: + thomaspinckney3
messages: +
2012-05-06 17:31:09
trent
set
messages: +
2012-05-06 13:29:32
ned.deily
set
messages: +
2012-05-06 09:47:24
maker
set
nosy: + maker
messages: +
2012-05-06 09:16:27
trent
set
nosy: + trent
messages: +
2012-04-28 23:04:58
hynek
set
nosy: + hynek
2012-03-13 06:26:36
ezio.melotti
link
2012-02-22 22:39:02
ned.deily
set
messages: +
2012-02-22 18:20:33
michael.foord
set
messages: +
2012-02-22 17:16:28
Anton.Korobeynikov
set
nosy: + Anton.Korobeynikov
2012-02-04 16:49:36
ned.deily
set
messages: +
stage: test needed
2012-01-12 07:03:53
ronaldoussoren
set
messages: +
2012-01-12 00:08:25
Nam.Nguyen
set
messages: +
2012-01-11 21:56:04
ronaldoussoren
set
keywords: + patch, needs review
files: + issue13241.patch
messages: +
2012-01-10 07:44:24
ronaldoussoren
set
messages: +
2012-01-10 07:17:23
ronaldoussoren
set
messages: +
2012-01-10 01:36:03
ned.deily
set
messages: +
2012-01-10 00:34:27
gvanrossum
set
nosy: + gvanrossum
messages: +
2011-12-28 02:47:43
Nam.Nguyen
set
messages: +
2011-12-13 22:00:58
ronaldoussoren
set
type: compile error
messages: +
nosy: + ronaldoussoren
2011-12-13 19:23:53
Nam.Nguyen
set
nosy: + Nam.Nguyen
2011-11-20 00:57:26
michael.foord
set
messages: +
2011-11-08 18:27:19
Yury.Selivanov
set
nosy: + Yury.Selivanov
2011-11-08 08:46:22
ned.deily
set
messages: +
2011-11-08 07:50:18
xapple
set
messages: +
2011-11-07 23:35:47
michael.foord
set
messages: +
2011-11-07 23:19:25
michael.foord
set
nosy: + michael.foord
messages: +
2011-11-04 17:17:49
xapple
set
messages: +
2011-11-04 16:37:38
ned.deily
set
messages: +
2011-11-04 14:42:46
xapple
set
nosy: + xapple
messages: +
2011-10-28 15:26:53
barry
set
nosy: + barry
2011-10-27 21:58:05
Julian
set
messages: +
2011-10-27 21:12:09
ned.deily
set
messages: +
2011-10-27 20:24:23
Julian
set
messages: +
2011-10-27 19:45:52
Julian
set
nosy: + Julian
2011-10-26 16:40:00
ned.deily
set
messages: +
2011-10-26 11:52:50
vstinner
set
messages: +
title: llvm-gcc-4.2 miscompiles Python (XCode 4.1+ on Mac OS 10.7) -> llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
2011-10-26 11🔞09
vstinner
set
title: Assertion failed in _PyUnicode_CheckConsistency during build of default branch on Mac OS X -> llvm-gcc-4.2 miscompiles Python (XCode 4.1+ on Mac OS 10.7)
2011-10-24 06:30:11
ned.deily
set
messages: +
2011-10-23 18:35:33
vstinner
set
messages: +
2011-10-23 17:06:25
Oleg.Plakhotnyuk
set
messages: +
2011-10-23 16:17:03
ned.deily
set
status: pending -> open
priority: normal -> high
components: + macOS
assignee: ned.deily
messages: +
type: compile error -> (no value)
resolution: fixed -> (no value)
2011-10-23 10:46:12
Oleg.Plakhotnyuk
set
status: open -> pending
2011-10-23 10:39:22
Oleg.Plakhotnyuk
set
status: pending -> open
resolution: works for me -> fixed
2011-10-23 10:38:27
Oleg.Plakhotnyuk
set
status: open -> pending
2011-10-23 10:35:58
Oleg.Plakhotnyuk
set
resolution: works for me
2011-10-23 10:33:23
Oleg.Plakhotnyuk
set
messages: +
2011-10-21 21:35:19
ezio.melotti
set
messages: +
2011-10-21 21:33:22
ned.deily
set
nosy: + ned.deily
messages: +
2011-10-21 19:55:51
ezio.melotti
set
nosy: + ezio.melotti
messages: +
2011-10-21 19:54:59
vstinner
set
messages: +
2011-10-21 19:53:31
vstinner
set
components: + Build
versions: + Python 3.3
2011-10-21 19:53:19
vstinner
set
files: + unicode.c
nosy: + vstinner
messages: +
2011-10-21 19:52:36
Oleg.Plakhotnyuk
set
messages: +
2011-10-21 19:49:19
Oleg.Plakhotnyuk
create