Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
build failure with Xcode 10 - libstdc++ not supported anymore #23424
Code Sample, a copy-pastable example if possible
(pandas-dev) bilbo:pandas-rb robertbuckley$ python setup.py build_ext --inplace -j 4 running build_ext building 'pandas._libs.window' extension gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/robertbuckley/anaconda3/envs/pandas-dev/include -arch x86_64 -I/Users/robertbuckley/anaconda3/envs/pandas-dev/include -arch x86_64 -Ipandas/_libs -I./pandas/_libs -Ipandas/_libs/src/klib -Ipandas/_libs/src -I/Users/robertbuckley/anaconda3/envs/pandas-dev/lib/python3.6/site-packages/numpy/core/include -I/Users/robertbuckley/anaconda3/envs/pandas-dev/include/python3.6m -c pandas/_libs/window.cpp -o build/temp.macosx-10.7-x86_64-3.6/pandas/_libs/window.o -Wno-unused-function warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found] pandas/_libs/window.cpp:655:10: fatal error: 'ios' file not found #include "ios" ^~~~~ 1 warning and 1 error generated. error: command 'gcc' failed with exit status 1
I setup a dev environment on Mac OS 10.13 according to https://pandas.pydata.org/pandas-docs/stable/contributing.html#creating-a-development-environment and all was well
Upgraded to 10.14 (mojave) and Xcode 10, and now i get the above failure.
Xcode 10 release notes includes the following deprecation notice
Building with libstdc++ was deprecated with Xcode 8 and is not supported in Xcode 10 when targeting iOS. C++ projects must now migrate to libc++ and are recommended to set a deployment target of macOS 10.9 or later, or iOS 7 or later. Besides changing the C++ Standard Library build setting, developers should audit hard-coded linker flags and target dependencies to remove references to libstdc++ (including -lstdc++, -lstdc++.6.0.9, libstdc++.6.0.9.tbd, and libstdc++.6.0.9.dylib). Project dependencies such as static archives that were built against libstdc++ will also need to be rebuilt against libc++. (40885260)
Some workaround suggestions are at https://stackoverflow.com/questions/52425766/stdlibc-headers-not-found-error-on-xcode-10 and the answer its linked to.
I dont have access to Xcode 9 anymore, so i can't try the workaround of copying the old libs from there
@TomAugspurger i already did that, to fix another issue. Now when I enter
I've updated to xcode 10.1, the issue is still there. Tomorrow I'll try to install Xcode 9 again.
Might there be a case for moving to libc++ anyway ?
i managed to get it building by deleting Xcode, and dowloading + installing Xcode 9.4.1 Command Line Tools from the Apple Developer website.
There is still something funny going on, because I then installed Xcode 10 Command Line Tools (after first renaming the old ones at
I'll continue to investigate, if thats OK
Not sure if it's the same issue or if this is a good fix, but I also couldn't build after updating to mojave (I got my error at a different point though). I fixed it by adding the argument
Credit for idea here
Here's my error log before performing the above step:
cython/cython#2694 also suggests that upgrading the command line tools was sufficient.
@JustinZhengBC, did you get the same error (without the extra link args) in a clean environment? Or was this in the same environment (with previously compiled files) from before you upgraded your command line tools?
I tried renaming the Cellar folder and running build, but it still failed.
However, I did manage to get it building without extra arguments after running
A fresh install of the latest Xcode and command line tools can build with no errors and no prompts. However, while I can get old versions of Xcode from the Apple developer's website, those seem to be standalones so I can't replicate the update process.
i managed to repro the issue on my system with the following sequence of steps:
After this I could reproduce the original failure mode i reported, and could get the extensions compiling OK using a variant of the fix proposed by @JustinZhengBC:
Probably these changes should be wrapped with a check for Mac OS >= 10.9 to avoid breaking other platforms.
If i added only the part in extra_link_args, I see the compiler error i originally reported:
If i added only the extra_compile_args part, the compile succeeds but the linker would throw an error:
My working theory is that the older version of Xcode command line tools adds the headers into /usr/include and the libstdc++ binaries into somewhere like /usr/lib, and that subsequent uninstalls of Xcode / Command Line Tools don’t remove them.
possibly useful liinks
referenced this issue
Nov 18, 2018
added a commit
Nov 27, 2018
hi @WillAyd the behaviour seems to depend if clang is able to find stdlibc++ headers/libs. This depends on the xcode install history, hence the difficulty in reproducing this.
i suppose there are 2 options: (1) require the user to workaround this by installing stdlibc++ or (2) change mac os targets to build + link libc++.
So far i am unable to get (1) working again on my system. I've tried:
But after each step I get the original compile error I reported.
for option 2 i've created a PR. I didn't meant to preempt any decision on taking this - its my first PR and i didnt realise that pushing a branch to my fork would update the GH issue. CI is running now with travis, azure (passed), circle ci, appveyor (passed)
please let me know how you'd like to proceed
Hmm is our only requirement for the C++ headers/libs stemming from this?
Not saying it's worth changing here but curious if we previously looked at the performance difference in linking against the c++ implementation vs using
Hi, I got to the bottom of this issue, in the end, after a trawl through clang, distutils and python make/config files.
The compiler standard library defaults to either
Recent macOS versions of python have a 64-bit only variant built for 10.9 (python.org), and a universal 64/32-bit variant built for 10.6 (python.org) or 10.7 (conda). I am running the conda universal variant, so
It may work for some users, for 1 of 2 reasons:
I've pushed a revised change which sets the targeted macOS to 10.9, when running on a 10.9 or above system, with a python/distutils which targets pre-10.9. This should not break builds on pre-10.9 systems, unlike my previous approach. It fixes the issue on my system. CI is running now.
Please let me know if you'd like me to submit it as a PR (assuming CI passes)