I'm compiling C++ code in macOS 10.13 / 10.14 that makes use of features of std::filesystem that aren't normally available until macOS 10.15. As a result, I'm getting errors like this:
error: '~path' is unavailable: introduced in macOS 10.15
However, I'm linking against the static libraries of a custom-built, up-to-date version of libc++, and so these errors are irrelevant as the version of libc++ I'm using does indeed support these features, and will compile in versions of macOS prior to 10.15.
How do I disable those error messages? I'm certain there's a command line option that does it because I've used it before, but I can't for the life of me remember what it is!
As per documentation, you can use -nostdlib++ and -nostdinc++ to supress default stdlib include and linking paths:
% clang++ -nostdinc++ -nostdlib++ \
-isystem <install>/include/c++/v1 \
-L <install>/lib \
-Wl,-rpath,<install>/lib \
-lc++ \
test.cpp
Another unofficial and probably unsupported solution is to define the macro _LIBCPP_DISABLE_AVAILABILITY. So the compilation command line argument -D_LIBCPP_DISABLE_AVAILABILITY avoids these errors.
Related
I've built LLVM and Clang from sources using following instruction in order to try some of the latest C++ features.
When I try to compile basic C++ program using this clang I get errors about missing basic headers:
% /usr/local/bin/clang++ -std=c++20 main.cpp
In file included from main.cpp:1:
main.cpp:3:10: fatal error: 'array' file not found
#include <array>
I similarly have brew installed clang, which works perfectly.
The instruction mentions providing C++ library headers to clang, but I don't understand:
How to locate those?
How to make sure, that they are also up to date to support latest C++ features?
I have MacOS Monterey 12.4
You should specify a path to the sdk for your target platform.
You can retreive this by relying on xcrun:
/usr/local/bin/clang++ -isysroot $(xcrun --show-sdk-path) -std=c++20 main.cpp
In case you want to target other platforms (in the example bellow, for iphone) you have to specify both the target triple and the path to the appropiate sdk:
/usr/local/bin/clang++ -target arm64-apple-ios -isysroot $(xcrun --sdk iphoneos --show-sdk-path) -std=c++20 main.cpp
There is also an alternative to the -isysroot option. You could set up the SDKROOT environment variable to point to the target sdk path:
export SDKPATH=$(xcrun --show-sdk-path)
/usr/local/bin/clang++ -std=c++20 main.cpp
I have an old Mac (circa 2009) running El Capitan version 10.11.6. Apple doesn't allow further updates of its OS on my machine, but through Macports it serves as a fine development environment for non-Apple-specific software.
I'm compiling with g++ 9.2, which supports std::filesystem out of the box, and with clang 8.0, which doesn't. (Using each compiler's native standard library, in each case.) And I'm compiling with --std=c++2a.
I've noticed the llvm 9 is supposed to support std::filesystem out of the box (https://libcxx.llvm.org/docs/UsingLibcxx.html#using-filesystem), so I downloaded clang/llvm 9 through Macports. Unfortunately, I'm hitting a snag.
Minimal code to reproduce error is a simplification of the example from cppreference.com (https://en.cppreference.com/w/cpp/filesystem/path/path)
#include <filesystem>
#include <iostream>
namespace fs = std::filesystem;
int
main()
{
fs::path p1 = "/usr/lib/sendmail.cf";
std::cout << "p1 = " << p1 << '\n';
}
And here's the CmakeLists.txt
cmake_minimum_required(VERSION 3.15.5)
project(bug LANGUAGES CXX)
add_executable (bug main.cpp)
target_compile_options(bug PRIVATE "-std=c++2a")
And here's the compiler's complaints:
[build] Starting build
[proc] Executing command: /opt/local/bin/cmake --build ~/temp/build/debug/clang --config debug --target all -- -j 10
[build] [1/2 50% :: 1.598] Building CXX object CMakeFiles/bug.dir/main.cpp.o
[build] FAILED: CMakeFiles/bug.dir/main.cpp.o
[build] /opt/local/bin/clang++ -g -std=c++2a -MD -MT CMakeFiles/bug.dir/main.cpp.o -MF CMakeFiles/bug.dir/main.cpp.o.d -o CMakeFiles/bug.dir/main.cpp.o -c ../../../main.cpp
[build] ../../../main.cpp:9:8: error: 'path' is unavailable: introduced in macOS 10.15
[build] fs::path p1 = "/usr/lib/sendmail.cf";
[build] ^
[build] /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/filesystem:738:24: note: 'path' has been explicitly marked unavailable here
[build] class _LIBCPP_TYPE_VIS path {
...
Working backward, I find this bit of code in /opt/local/libexec/llvm-9.0/include/c++/v1/__config:
# define _LIBCPP_AVAILABILITY_FILESYSTEM \
__attribute__((availability(macosx,strict,introduced=10.15))) \
__attribute__((availability(ios,strict,introduced=13.0))) \
__attribute__((availability(tvos,strict,introduced=13.0))) \
__attribute__((availability(watchos,strict,introduced=6.0)))
As far as I can determine, this #define is the ultimate cause of the above error message.
So, my questions are:
Is this a bug with LLVM? After all, GCC doesn't introduce a dependency between std::filesystem and the OS version.
Is this a bug with Macports? Maybe they didn't use the correct flags when building?
If I were to build LLVM and Clang natively, can I work around this issue?
Is it an issue at all? Maybe the good folks at LLVM know something that the good folks at GCC don't.
NOTE: There's a similar question involving clang/llvm downloaded through Homebrew. Unfortunately, the commentary was not helpful. [LLVM-9 clang-9 OSX]: std::filesystem::path unrecognized
I've been looking through LLVM and encountered the following lines:
// Decide whether to use availability macros.
#if !defined(_LIBCPP_BUILDING_LIBRARY) && \
!defined(_LIBCPP_DISABLE_AVAILABILITY) && \
__has_feature(attribute_availability_with_strict) && \
__has_feature(attribute_availability_in_templates)
# ifdef __APPLE__
# define _LIBCPP_USE_AVAILABILITY_APPLE
# endif
#endif
So I passed -D_LIBCPP_DISABLE_AVAILABILITY to the compiler and it worked! I doubt that it's a valid solution, but it may help someone. Another option could be sticking to https://github.com/gulrak/filesystem which is basically std::filesystem, but outside of the standard library.
Answering some of your questions:
Is this a bug with LLVM? After all, GCC doesn't introduce a dependency between std::filesystem and the OS version.
Well, it's not a bug, but yes, it's a feature of LLVM and it seems that it's made especially for Apple.
Is this a bug with Macports? Maybe they didn't use the correct flags when building?
No, it's not a bug of Macports or Homebrew.
If I were to build LLVM and Clang natively, can I work around this issue?
As you could see this availability feature is in the sources, so it seems that it doesn't matter if you build it from sources or using a package manager.
Is it an issue at all? Maybe the good folks at LLVM know something that the good folks at GCC don't.
Unfortunately, I can't state anything here, but it should've been done for a reason.
After installing clang++ (tried v. 6.0.1 and 7.0) with:
brew install --with-toolchain llvm
very trivial programs result to the following error:
In file included from test.cpp:1:
In file included from /usr/local/Cellar/llvm/7.0.0/include/c++/v1/iostream:38:
In file included from /usr/local/Cellar/llvm/7.0.0/include/c++/v1/ios:215:
In file included from /usr/local/Cellar/llvm/7.0.0/include/c++/v1/iosfwd:90:
/usr/local/Cellar/llvm/7.0.0/include/c++/v1/wchar.h:119:15: fatal error: 'wchar.h' file not found
#include_next <wchar.h>
Command used to compile:
clang++7() {
LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"
CPPFLAGS="-I/usr/local/opt/llvm/include"
/usr/local/opt/llvm/bin/clang++ -std=c++11 $CPPFLAGS $LDFLAGS $1
}
Is it possible to use the official clang instead of Apple's version?
With Apple's version, we do not even know which version of LLVM it really is...
It appears that as of Mojave (10.14), Xcode doesn't install system headers in /usr/include anymore. There is a compatibility package that does, but it's not recommended.
Instead, the official solution is for tools to search for headers in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk. That path can be obtained from
xcrun --show-sdk-path
The release notes say
The Command Line Tools package installs the macOS system headers inside the macOS SDK. Software that compiles with the installed tools will search for headers within the macOS SDK provided by either Xcode at:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
or the Command Line Tools at:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
depending on which is selected using xcode-select.
If you built clang yourself, this can be achieved by passing the -isysroot option to clang:
clang++ -isysroot "$(xcrun --show-sdk-path)" …
See also: https://github.com/Homebrew/homebrew-core/issues/32765
It works for me to add a -I (minus eye) option to the clang++ command line, pointing to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include
I want to replace gcc with clang (3.3) to build my C++11 code, so I should use clang's option -stdlib=libstdc++ (to make it see STL headers). The option works: clang see headers like string, but can't find c++11 headers (type_traits) because clang searches in 4.2 directories:
clang++ -stdlib=libstdc++ -E -x c++ - -v < /dev/null
...
/usr/include/c++/4.2
/usr/include/c++/4.2/backward
/usr/include/clang/3.3
/usr/include
...
How to make it look at never versions of GCC's headers?
As far as I understand, only libc++ (not libstdc++) is supported by clang for C++11 so the only way it so install libc++?
Either uninstall gcc 4.2 or use the --gcc-toolchain=<value> option.
--gcc-toolchain=<value> Use the gcc toolchain at the given directory
For example: clang++ --gcc-toolchain=/usr/local/... -stdlib=libstdc++ ...
As far as I understand, only libc++ (not libstdc++) is supported by clang for C++11 so the only way it so install libc++?
Both C++ standard libraries are supported.
I have Xcode 4.5.2 on Moutain Lion, and I have install the lastest "Command Line Tools" but when I tried to compile with g++ or clang++ (and the options -std=c++11 -stdlib=libc++) I get an error.
With g++:
cc1plus: error: unrecognized command line option "-std=c++11"
cc1plus: error: unrecognized command line option "-stdlib=libc++"
With clang++:
clang: error: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or later)
It's in a Qt project.
So how can I used the C++11 on my Mac ?
As you found, g++ does not support those command line options.
It sounds like you're using Xcode.
For clang, you should look at the project settings, and make sure that the "Deployment Target" is set to 10.7 (or 10.8)
What the error message is telling you is that libc++ is not available for 10.6 and before.
I installed gcc-4.7 on my Mac to make C++11 work. GCC in its current version is fairly good at supporting C++11, so this should be a fair choice.
The installation can be done by Homebrew and is not that complicated (at least I was able to do it...)
To install Homebrew if you do not already have it:
ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"
Now run
brew doctor
and fix whatever problems come up (there is something written in the hombrew documentation for that). Finally, install current gcc:
brew install gcc
If everything goes well you should be able to access g++-4.7, which allows -std=c++0x.
Try -std=c++0x if c++11 doesn't work. Support for the -std=c++11 option is relatively new in GCC and you might not have a recent enough version.
I'd trust Marshall on the libc++ issue.