macOS-latest's C++ environment seems incomplete: -stdlib=libc++ being ignored

[ltcmelo]

Describe the bug
It appears to me that the C++ environment for macOS-latest (with the clang compiler) is incomplete. Specifically, it doesn't seem to be possible to build against a C++11 (or later) standard library implementation, e.g., libstdc++ or libc++. An official description of the role of libc++ in osx is available here -- there's also plenty of discussion around online.

Area for Triage:

Question, Bug, or Feature?:
A bug.

Virtual environments affected

• macOS 10.15
• Ubuntu 16.04 LTS
• Ubuntu 18.04 LTS
• Windows Server 2016 R2
• Windows Server 2019

Expected behavior
See a successful compilation on ubuntu-latest.

Actual behavior

See this compilation error on macOS-latest.

[Geod24]

Your problem is here. Why are you trying to link against libstdc++ ? Apple only distributes an old version which is not C++11 compatible. libc++ is what you want to use on recent OSX versions, without exception. A custom clang will actually emit a warning if you try to link with libstdc++ because its usage is deprecated.

Also see this stackoverflow answer.

Side note: You might want to use CXX_STANDARD (or it's _REQUIRED equivalent) in your CMakeList instead of setting the flag yourself.

[ltcmelo]

Your problem is here. Why are you trying to link against libstdc++?

@Geod24, I'm not linking against libstdc++, but against libc++. Check the link mentioned by yourself (in a earlier commit, though, I attempted passing libstdc++ for investigation purposes).

In fact, I only added explicit link information because, with the default settings, I was already getting the error. Thanks for the hint about CXX_STANDARD, I'll give it a try.

[Geod24]

My bad, I got things quite mixed up. I have a project where I build C++ code using C++14 and the native toolchain, and things are working just fine, so I am pretty sure that the Github environment is fine. However said project is using its own build system, so I can't provide an example with CMake.

Can you provide the command where clang is invoked?
I would imagine either -std=c++14 is not passed for some reason, or clang is invoked as clang instead of clang++ (that was a problem for us in the past).

[ltcmelo]

I've tried CXX_STANDARD but the issue remains. From a bit more googling, this seems to be libc++ regression -- that might reproduce for certain #include ordering. (I'm actually developing on OSX myself.)

[maxim-lobanov]

Hello @ltcmelo ,
I think I have found something:

1. By default, Clang 11 (distributed with active Xcode) is used for build - your repro project failed with this configuration
2. If we switch to Clang 9 (that is installed with brew install llvm), repro project still fails to build
3. If we switch to Clang 10, repro project builds successfully.
   Link to the successful build: https://github.com/maxim-lobanov/psychec/runs/574694963?check_suite_focus=true

To switch to Clang 10, we need to use the following steps:

  steps:
    - uses: actions/checkout@v2
    - name: Update clang
      run: |
        brew update
        brew upgrade llvm # temporary step because macOS image still contains Clang 9 by default
    - name: configure
      run: |
        export CXX="/usr/local/opt/llvm/bin/clang++" # Switch to Clang 10
        cmake CMakeLists.txt
    - name: make
      run: make

Please pay attention that Update clang step takes some time to run. We need to use it because llvm brew formula was updated from Clang 9 to Clang 10 recently but the image is not updated yet. This step will become unnecessary in 1 week.

Unfortunately, I am not super familiar with Clang / g++ so I can't explain the root cause why Clang 11 doesn't work as expected but hope the steps above will help you

[ltcmelo]

Thanks @maxim-lobanov , I'll give it a try.

[dmitry-shibanov]

Hello @ltcmelo , did it work for you ?

[ltcmelo]

Hi @dmitry-shibanov , just gave it a try and it worked. FYI, this is how the workflow looks now.

Thanks again 👍

[dmitry-shibanov]

Hello @ltcmelo , thank you for your response. I closed the issue but if you have any concerns feel free to reopen the issue.

[ltcmelo]

In case anyone runs into this problem... Once I've updated my system (and reproduced the issue locally), tracked the root cause of the problem. There's apparently been a change in the search paths behavior libc++: now, either it respects paths passed through -I -- in case-insensitive manner; the Assert.h file of my project was being picked up instead of standard's assert.