Use -stdlib=libc++ on macOS

[Ceylo]

Forum thread

https://en.sfml-dev.org/forums/index.php?topic=22786.msg159283#msg159283

Rationale

The standard library "stdc++" causes warnings when linking on macOS:
clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]

Build logs in SFML CI show this too. Also current downloads for macOS are built with libc++, so the CI doesn't build with what's currently shipped.

Regarding any possible compatibility issue, note that libc++ is available since macOS 10.7.

@mantognini Should CMAKE_OSX_DEPLOYMENT_TARGET also be changed from 10.7 to 10.9 as suggested by the deprecation warning?

[Foaly]

Nice fix! I have a similar problem on OSX when I built SFML using Clang and CMake in QtCreator. I got linker errors when using the so compiled SFML in a project which uses the same setup. The linker errors point to a mismatch in standart library versions. I was not able to find the root of the mismatch, but compiling SFML with set(CMAKE_CXX_FLAGS "-stdlib=libc++") fixed the problem for me. Thank you for taking care of this!

[mantognini]

Thanks!

We can keep CMAKE_OSX_DEPLOYMENT_TARGET to 10.7 for now I think but at some point we'll indeed drop support for older releases of macOS.

Just a quick question about this PR: I've noticed a specific Xcode attribute. Is it absolutely necessary? Are there others such settings we should/could be using?

[Foaly]

I just gave this a test and can confirm that it indeed fixes the linker issues I had. 👍

[Ceylo]

@mantognini For the Xcode attribute, it is not mandatory but is just for better integration in Xcode. With the Xcode attribute, in build settings for the standard library entry it will show libc++. If you set the CMAKE_CXX_FLAGS with Xcode generator, in build settings the standard library entry will just remain « Default for compiler » and you’ll have -stdlib=libc++ in « Other C++ flags ».

And no I don’t know about other attributes to set right now. Also it’s usually a better idea to set a compilation flag rather than an Xcode attribute so that it works with any generator.

(NB: I rebased on master so you should relaunch CI builds)

@Foaly Nice that it solved your problems too :) Working with Xcode for another PR I got bored to manually change that setting after each CMake generation.

[mantognini]

Alright, looks good to me!

[Foaly]

I ran into this problem again today and it cost me about half an hour before I figured out it was this again...
Can I haz merge plz?

[eXpl0it3r]

Merged in 511c163

[barracuda156]

@mantognini @Ceylo This is wrong to hardcode runtime library and it breaks builds with GCC. A correct fix would be to use Clang library only with Clang, obviously.

[eXpl0it3r]

GCC fails for other reasons on macOS currently. If you find out how to fix the generated errors, then we're more than happy to merge a fix.

[barracuda156]

GCC fails for other reasons on macOS currently. If you find out how to fix the generated errors, then we're more than happy to merge a fix.

@eXpl0it3r ObjC garbage fails, I suspect. I am not sure Cocoa will be fixable on my system (it should be possible to rewrite it in normal C/C++, but I can’t), but it should work on a modern macOS. Can you refer to the issue, what fails with GCC build?

[eXpl0it3r]

Related issues: #1229 #2582 #2584

[barracuda156]

@eXpl0it3r Thank you. I think I saw that sign conversion error referred to in #2582
gcc-4.9 issues may not be relevant, it is an archaic version, no reason to even consider using it. The latest gcc support macOS back to 10.5, including PowerPC.
For ObjC, it might be needed to switch to generic Unix build on older macOS.

[VictorEijkhout]

FYI, this breaks with clang too:

[ 58%] Building C object src/SFML/Window/CMakeFiles/sfml-window.dir/OSX/SFApplication.m.o
cd /Users/eijkhout/Installation/sfml/build-2.6.0-macbookair-clang16/src/SFML/Window && /opt/local/bin/clang-mp-16 -DSFML_WINDOW_EXPORTS -I/Users/eijkhout/Installation/sfml/sfml-2.6.0/include -I/Us
ers/eijkhout/Installation/sfml/sfml-2.6.0/src -I/Users/eijkhout/Installation/sfml/sfml-2.6.0/extlibs/headers/vulkan -isystem /Users/eijkhout/Installation/sfml/sfml-2.6.0/extlibs/headers/glad/inclu
de -iframework /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/System/Library/Frameworks -O3 -DNDEBUG -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk -mmacosx
-version-min=11.6 -fPIC -fvisibility=hidden -stdlib=libc++  -Wall -Wextra -Wshadow -Wnon-virtual-dtor -Wcast-align -Wunused -Woverloaded-virtual -Wconversion -Wsign-conversion -Wdouble-promotion -
Wformat=2 -Wnull-dereference -Wold-style-cast -Wpedantic -Werror -Wno-unknown-warning-option -MD -MT src/SFML/Window/CMakeFiles/sfml-window.dir/OSX/SFApplication.m.o -MF CMakeFiles/sfml-window.dir
/OSX/SFApplication.m.o.d -o CMakeFiles/sfml-window.dir/OSX/SFApplication.m.o -c /Users/eijkhout/Installation/sfml/sfml-2.6.0/src/SFML/Window/OSX/SFApplication.m
clang: error: argument unused during compilation: '-stdlib=libc++' [-Werror,-Wunused-command-line-argument]
make[3]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/OSX/SFApplication.m.o] Error 1
make[2]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/all] Error 2

Note that it breaks late in the build process. Also: I don't like Wno-error because that make the build system dependent, namely through what the particular compiler considers worth warning about.

[ChrisThrasher]

#2625

That warning has already been fixed

[VictorEijkhout]

Confirm. Clang build succeeds cleanly with latest git pull.

[eXpl0it3r]

Duplicates #2790