Title: llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)
Type: compile error Stage: committed/rejected
Components: Build, Macintosh Versions: Python 3.3
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: ned.deily Nosy List: Anthony.Kong, Anton.Korobeynikov, Julian, Nam.Nguyen, Oleg.Plakhotnyuk, Yury.Selivanov, barry, eric.araujo, ezio.melotti, gvanrossum, haypo, hynek, maker, michael.foord, ned.deily, ronaldoussoren, thomaspinckney3, trent, xapple
Priority: high Keywords: needs review, patch

Created on 2011-10-21 19:49 by Oleg.Plakhotnyuk, last changed 2012-09-05 15:19 by ronaldoussoren. This issue is now closed.

File name Uploaded Description Edit
unicode.c haypo, 2011-10-21 19:53
issue13241.patch ronaldoussoren, 2012-01-11 21:56 review ronaldoussoren, 2012-06-13 21:23
issue13241-configure-version1.txt ronaldoussoren, 2012-06-13 23:57 review
Messages (49)
msg146120 - (view) 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 <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
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!
msg146121 - (view) 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
msg146122 - (view) Author: STINNER Victor (haypo) * (Python committer) 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".
msg146123 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-10-21 19:54
The bug has been fixed in GCC, try a more recent version using ./configure CC=gccX.Y.
msg146124 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-10-21 19:55
It should also work without --with-pydebug, or with a different compiler.
msg146136 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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.
msg146137 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-10-21 21:35
See also
msg146223 - (view) 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:
1. Install XCode 4.2
2. Install MacPorts
3. sudo port -v selfupdate
4. sudo port install gcc46
5. ./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?
msg146233 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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.
msg146234 - (view) 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
msg146240 - (view) Author: STINNER Victor (haypo) * (Python committer) 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?
msg146279 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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.
msg146433 - (view) Author: STINNER Victor (haypo) * (Python committer) 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.
msg146444 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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.
msg146517 - (view) 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.

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.
msg146519 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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.
msg146521 - (view) 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.
msg147006 - (view) 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.
msg147014 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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)?
msg147018 - (view) 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)
msg147265 - (view) Author: Michael Foord (michael.foord) * (Python committer) 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
msg147267 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2011-11-07 23:35
Ah, it seems I have XCode 3.2.6 installed alongside XCode 4.2.
msg147275 - (view) 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 ?

Shouldn't the latest version of OS X be included in the list of *nix systems that cpython is checked to build on ?
msg147279 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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.
msg147974 - (view) Author: Michael Foord (michael.foord) * (Python committer) 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
msg149410 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) 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/
/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 ./ 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();

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
msg150278 - (view) 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
msg150992 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) 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.
msg150994 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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.
msg151006 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) 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?
msg151007 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) 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.
msg151093 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) 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 @@
-     "the typecode character used to create the array"}
+     "the typecode character used to create the array"},
 /* -------------------------------------------------------*/

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.
msg151099 - (view) 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.
msg151116 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) 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).
msg152634 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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 

/usr/bin/gcc-4.2 --version
./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).
msg153981 - (view) Author: Michael Foord (michael.foord) * (Python committer) 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:

msg154004 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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:

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/; 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.
msg160064 - (view) Author: Trent Nelson (trent) * (Python committer) 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, logged in with my Apple ID, then downloaded 'Commandline Tools for XCode - Late March 2012' -- dmg was 'cltools_lion_latemarch12.dmg'.
msg160066 - (view) 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.
msg160081 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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?
msg160099 - (view) Author: Trent Nelson (trent) * (Python committer) 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).
msg160353 - (view) 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)
msg162090 - (view) Author: Hynek Schlawack (hynek) * (Python committer) 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. :)
msg162093 - (view) Author: Ned Deily (ned.deily) * (Python committer) 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).
msg162728 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2012-06-13 21:23
The attached 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 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).
msg162742 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2012-06-13 23:57
The attached patch "issue13241-configure-version1.txt" implements a number of changes to configure (although only is present in the patch)

1) 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)

2) 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

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
  on systems with other compiler versions and installed SDKs
msg169831 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) 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.
msg169833 - (view) Author: Lucas Sinclair (xapple) Date: 2012-09-04 14:00
I agree to close the issue. I tried following the steps proposed here:

And typed these two commands on a OS X 10.8.1 with XCode and command line tools installed.

$ hg clone
$ run ./configure --with-pydebug && make -j2

Python built perfectly.
msg169875 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) 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).
Date User Action Args
2012-09-05 15:19:35ronaldoussorensetstatus: open -> closed
resolution: wont fix
messages: + msg169875

stage: test needed -> committed/rejected
2012-09-04 14:00:22xapplesetmessages: + msg169833
2012-09-04 13:20:25ronaldoussorensetmessages: + msg169831
2012-06-27 11:28:03Anthony.Kongsetnosy: + Anthony.Kong
2012-06-16 16:25:36eric.araujosetnosy: + eric.araujo
2012-06-13 23:57:57ronaldoussorensetfiles: + issue13241-configure-version1.txt

messages: + msg162742
2012-06-13 21:23:23ronaldoussorensetfiles: +

messages: + msg162728
2012-06-01 18:13:55ned.deilysetmessages: + msg162093
2012-06-01 18:04:10hyneksetmessages: + msg162090
2012-06-01 17:54:27hyneklinkissue14981 superseder
2012-05-28 11:39:52hyneklinkissue14932 superseder
2012-05-10 15:41:40thomaspinckney3setnosy: + thomaspinckney3
messages: + msg160353
2012-05-06 17:31:09trentsetmessages: + msg160099
2012-05-06 13:29:32ned.deilysetmessages: + msg160081
2012-05-06 09:47:24makersetnosy: + maker
messages: + msg160066
2012-05-06 09:16:27trentsetnosy: + trent
messages: + msg160064
2012-04-28 23:04:58hyneksetnosy: + hynek
2012-03-13 06:26:36ezio.melottilinkissue14284 superseder
2012-02-22 22:39:02ned.deilysetmessages: + msg154004
2012-02-22 18:20:33michael.foordsetmessages: + msg153981
2012-02-22 17:16:28Anton.Korobeynikovsetnosy: + Anton.Korobeynikov
2012-02-04 16:49:36ned.deilysetmessages: + msg152634
stage: test needed
2012-01-12 07:03:53ronaldoussorensetmessages: + msg151116
2012-01-12 00:08:25Nam.Nguyensetmessages: + msg151099
2012-01-11 21:56:04ronaldoussorensetkeywords: + patch, needs review
files: + issue13241.patch
messages: + msg151093
2012-01-10 07:44:24ronaldoussorensetmessages: + msg151007
2012-01-10 07:17:23ronaldoussorensetmessages: + msg151006
2012-01-10 01:36:03ned.deilysetmessages: + msg150994
2012-01-10 00:34:27gvanrossumsetnosy: + gvanrossum
messages: + msg150992
2011-12-28 02:47:43Nam.Nguyensetmessages: + msg150278
2011-12-13 22:00:58ronaldoussorensettype: compile error

messages: + msg149410
nosy: + ronaldoussoren
2011-12-13 19:23:53Nam.Nguyensetnosy: + Nam.Nguyen
2011-11-20 00:57:26michael.foordsetmessages: + msg147974
2011-11-08 18:27:19Yury.Selivanovsetnosy: + Yury.Selivanov
2011-11-08 08:46:22ned.deilysetmessages: + msg147279
2011-11-08 07:50:18xapplesetmessages: + msg147275
2011-11-07 23:35:47michael.foordsetmessages: + msg147267
2011-11-07 23:19:25michael.foordsetnosy: + michael.foord
messages: + msg147265
2011-11-04 17:17:49xapplesetmessages: + msg147018
2011-11-04 16:37:38ned.deilysetmessages: + msg147014
2011-11-04 14:42:46xapplesetnosy: + xapple
messages: + msg147006
2011-10-28 15:26:53barrysetnosy: + barry
2011-10-27 21:58:05Juliansetmessages: + msg146521
2011-10-27 21:12:09ned.deilysetmessages: + msg146519
2011-10-27 20:24:23Juliansetmessages: + msg146517
2011-10-27 19:45:52Juliansetnosy: + Julian
2011-10-26 16:40:00ned.deilysetmessages: + msg146444
2011-10-26 11:52:50hayposetmessages: + msg146433
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:18:09hayposettitle: 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:11ned.deilysetmessages: + msg146279
2011-10-23 18:35:33hayposetmessages: + msg146240
2011-10-23 17:06:25Oleg.Plakhotnyuksetmessages: + msg146234
2011-10-23 16:17:03ned.deilysetstatus: pending -> open
priority: normal -> high

components: + Macintosh
assignee: ned.deily
messages: + msg146233
type: compile error -> (no value)
resolution: fixed -> (no value)
2011-10-23 10:46:12Oleg.Plakhotnyuksetstatus: open -> pending
2011-10-23 10:39:22Oleg.Plakhotnyuksetstatus: pending -> open
resolution: works for me -> fixed
2011-10-23 10:38:27Oleg.Plakhotnyuksetstatus: open -> pending
2011-10-23 10:35:58Oleg.Plakhotnyuksetresolution: works for me
2011-10-23 10:33:23Oleg.Plakhotnyuksetmessages: + msg146223
2011-10-21 21:35:19ezio.melottisetmessages: + msg146137
2011-10-21 21:33:22ned.deilysetnosy: + ned.deily
messages: + msg146136
2011-10-21 19:55:51ezio.melottisetnosy: + ezio.melotti
messages: + msg146124
2011-10-21 19:54:59hayposetmessages: + msg146123
2011-10-21 19:53:31hayposetcomponents: + Build
versions: + Python 3.3
2011-10-21 19:53:19hayposetfiles: + unicode.c
nosy: + haypo
messages: + msg146122

2011-10-21 19:52:36Oleg.Plakhotnyuksetmessages: + msg146121
2011-10-21 19:49:19Oleg.Plakhotnyukcreate