py27-wxpython-3.0 @3.0.2.0 fatal error: 'type_traits' file not found on systems upgraded to libc++

[kencu (Ken)]

wxpython build stalls on 10.6 with libc++ (and I will presume other systems upgraded to libc++ < 10.9) due to

fatal error: 'type_traits' file not found

the configuration phase gives a clue trouble is coming

checking how to run the C++ preprocessor... /opt/local/bin/clang++-mp-3.7 -E
checking type_traits usability... yes
checking type_traits presence... no
configure: WARNING: type_traits: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: type_traits: proceeding with the compiler's result
checking for type_traits... yes
checking for __sync_fetch_and_add and __sync_sub_and_fetch builtins... yes

which then fails during compilation:

creating build/temp.macosx-10.6-x86_64-2.7/src/osx_cocoa
/opt/local/bin/clang-mp-3.7 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch x86_64 -DSWIG_TYPE_TABLE=_wxPython_table -DSWIG_PYTHON_OUTPUT_TUPLE -DSWIG_PYTHON_SILENT_MEMLEAK -DWXP_USE_THREAD=1 -UNDEBUG -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__ -Iinclude -Isrc -I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxPython/3.0/lib/wx/include/osx_cocoa-unicode-3.0 -I/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxPython/3.0/include/wx-3.0 -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c src/helpers.cpp -o build/temp.macosx-10.6-x86_64-2.7/src/helpers.o -O3
In file included from src/helpers.cpp:17:
In file included from include/wx/wxPython/wxPython_int.h:35:
In file included from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxPython/3.0/include/wx-3.0/wx/wx.h:15:
In file included from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxPython/3.0/include/wx-3.0/wx/object.h:19:
In file included from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxPython/3.0/include/wx-3.0/wx/memory.h:15:
In file included from /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxPython/3.0/include/wx-3.0/wx/string.h:46:
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxPython/3.0/include/wx-3.0/wx/strvararg.h:25:14: fatal error: 'type_traits' file not found
    #include <type_traits>

the solution seems to be to get -stdlib=libc++ onto that build command line.

I tried various things, but in the end, adding the following bit to wxPython-src-3.0.2.0/wxPython/config.py in the darwin section worked.

    if sys.platform[:6] == "darwin":
        WXPLAT = '__WXMAC__'
    
        if WXPORT == 'osx_carbon':
        # Flags and such for a Darwin (Max OS X) build of Python
            GENDIR = 'osx_carbon'
            WXPLAT2 = '__WXOSX_CARBON__'
        else:
            GENDIR = 'osx_cocoa'
            WXPLAT2 = '__WXOSX_COCOA__'
+            cflags.append('-stdlib=libc++')
+            lflags.append('-stdlib=libc++')

I think only one of the the flag is actually used, but at this moment I'm not sure which one it is.

in the end, success:

$ port -v installed | grep py27-wxpython-3.0
  py27-wxpython-3.0 @3.0.2.0_0 (active) platform='darwin 10' archs='x86_64'

not completely sure how to fully test the functionality at present, however.

No doubt there are better ways to fix it, like rewriting the issue with the configure script to correctly decide whether to use type_traits.

Is this useful enough to you to have me build a patch for it? Or shall we just leave it as an available workaround for people?

[mojca (Mojca Miklavec)]

No, we should fix this properly rather than let users patch files manually.

I can imagine that this is a problem since I already had problems building wxWidgets-3.0 and had to add the following:

if {[string match *clang* ${configure.cxx}]} {
    configure.ldflags-append \
                    -stdlib=${configure.cxx_stdlib}
}

The main question is how to fix this properly and whether there is any way to submit this upstream / ask upstream to fix it. I reported the initial problem to wxWidgets developers, but they argued that whatever MacPorts is already setting is not sufficient.

[kencu (Ken)]

OK. I foresee a block like the one you have in wxWidgets making it into this port as well, ultimately.

For my education, can you tell me how it is that adding "-stdlib=libc++" to the build command allows the compiler to find the "type_traits" file? I know it works, but I don't understand why it works, exactly. -- K

[update] I see -- in the background, that flag changes the compiler's default include paths.

[mojca (Mojca Miklavec)]

​type_traits is part of C++11 standard.

The libstdc++ as shipped on OS X (I think it's version 2 or something) doesn't support C++11. If you want C++11, you need to switch to libc++ (or to gcc 4.7+ which then using its own libstdc++ version 3). In theory you would also need to add something like -std=c++11 to compiler flags, but on OS X you would automatically get (some?) C++11 features just by switching to libc++.

The problem you are experiencing is because wxWidgets' configure checks whether particular features are available and when you build it on a "libc++" installation, it would find the C++11 features and use them, but then during the linking the flag is apparently missing and it won't be able to find the features it found earlier.

[mojca (Mojca Miklavec)]

It's also possible that in case of wxPython the installation doesn't get any flags at all (and it should). But it uses an existing wxWidgets installation that was compiled with those flags and the installed wxWidgets headers claim the support for type_traits was there.

I should test this on 10.6 with libc++. It is not useful if I just keep guessing.

[mojca (Mojca Miklavec)]

I reassigned the ticket to myself, but if Jyrki wants to work on it ... go ahead.

[mojca (Mojca Miklavec)]

The official answer was that we should add -stdlib=libc++ to CC, so that the full compiler name is something like clang -stdlib=libc++.

[kencu (Ken)]

Turns out adding the -stdlib onto the CC compiler spec just doesn't work. A somewhat more complicated but functional fix is coming shortly as a PR.

[kencu (Ken)]

fixed by the improved stdlib defaulting I implemented