I have installed LLVM 5.0 on Windows 10 x64. When I call clang++ --version from cmd the message below is displayed.
clang version 5.0.0 (tags/RELEASE_500/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\LLVM\bin
But when I call qbs setup-toolchains --detect in the resulting list neither clang nor clang++ is in. If I call qbs config --list profiles both clang and clang++ are not in the list. Am I missing something?
On Windows, the --detect option only looks for MSVC and mingw installations. Use the explicit mode instead:
qbs setup-toolchains C:\LLVM\bin\clang.exe clang
Related
I'm trying to tailor compiler flags of clang-11 to the apple-m1 CPU, which clang-11 doesn't know about yet.
The output of /usr/bin/clang -E - -mcpu=apple-m1 -### on macOS outputs a command with flags like these in it: "-target-feature" "+zcz"
From that you can infer the following features of the CPU:
armv8.5a+fp-armv8+neon+crc+crypto+dotprod+fp16fml+ras+lse+rdm+rcpc+zcm+zcz+fullfp16+sm4+sha3+sha2+aes
However, out of these, +fp-armv8+neon+zcm+zcz+fullfp16 are not recognised to be valid by any clang compiler:
$ cc -march=armv8.5a+zcz test.c
clang-11: error: the clang compiler does not support '-march=armv8.5a+zcz'
How can I tell clang to optimise for those target flags?
I am trying to build LLVM compilers so that I can enable OpenMP on the Apple M1.
I am using the LLVM development tree, (since I saw some OpenMP runtime go into that for this recently).
I have ended up with this script to invoke cmake:
# Xcode, Ninja
BUILD_SYSTEM=Ninja
BUILD_TAG=Ninja
cmake ../llvm \
-G$BUILD_SYSTEM -B ${BUILD_TAG}_build \
-DCMAKE_OSX_ARCHITECTURES='arm64' \
-DCMAKE_C_COMPILER=`which clang` \
-DCMAKE_CXX_COMPILER=`which clang++` \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_BUILD_WITH_INSTALL_RPATH=1 \
-DCMAKE_INSTALL_PREFIX=$HOME/software/clang-12.0.0/arm64 \
-DLLVM_ENABLE_WERROR=FALSE \
-DLLVM_TARGETS_TO_BUILD='AArch64' \
-DLLVM_ENABLE_PROJECTS='clang;openmp,polly' \
-DLLVM_DEFAULT_TARGET_TRIPLE='aarch64-apple-darwin20.1.0'
The compilers used here are
$ /usr/bin/clang --version
Apple clang version 12.0.0 (clang-1200.0.32.27)
Target: arm64-apple-darwin20.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
ninja can then successfully build clang, clang++ and the OpenMp runtime and install them. (As simple, Arm64 images targeting Arms64)
$ file ~/software/clang-12.0.0/arm64/bin/clang
/Users/jcownie/software/clang-12.0.0/arm64/bin/clang: Mach-O 64-bit executable arm64
$ ~/software/clang-12.0.0/arm64/bin/clang --version
clang version 12.0.0 (https://github.com/llvm/llvm-project.git 879c15e890b4d25d28ea904e92497f091f796019)
Target: aarch64-apple-darwin20.1.0
Thread model: posix
InstalledDir: /Users/jcownie/software/clang-12.0.0/arm64/bin
Which all looks sane, except that when I try to compile anything with them they are missing the include path to get system headers.
$ ~/software/clang-12.0.0/arm64/bin/clang hello.c
hello.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^~~~~~~~~
1 error generated.
So, after all that,
Does anyone know how to fix that include path problem?
Does anyone know how to configure and build a fat binary for the compilers (and libraries) so that the x86_64 embedded compiler targets x86_64 and the aarch64 binary aarch64? (This is what the Xcode clang and clang++ do...)
My attempt at this ended up with a compiler fat binary where both architectures targeted x86_64 :-(
Thanks
You can set -DDEFAULT_SYSROOT=/path/to/MacOSX11.1.sdk at build time or do export SDKROOT=/path/to/MacOSX11.1.sdk at runtime.
You need to compile with clang -arch arm64 -arch x86_64 to get a fat binary out of clang. You need to do this for Apple clang as well.
UPDATED 8 Feb 2021
Homebrew now supports the M1 based Arm machines, so using that is a better answer than the one below.
The info below is potentially still useful if you want to do this on your own, but using brew is likely to be much simpler.
Pre-brew answer
I haven't found a clean solution, but in case it helps anyone else, I do have a horrible hack.
The full recipe, then is configure with this script, then build and install.
# Xcode, Ninja
BUILD_SYSTEM=Ninja
BUILD_TAG=ninja
INSTALLDIR=$HOME/software/clang-12.0.0/arm64
cmake ../llvm \
-G$BUILD_SYSTEM -B ${BUILD_TAG}_build \
-DCMAKE_OSX_ARCHITECTURES='arm64' \
-DCMAKE_C_COMPILER=`which clang` \
-DCMAKE_CXX_COMPILER=`which clang++` \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=$INSTALLDIR \
-DLLVM_LOCAL_RPATH=$INSTALLDIR/lib \
-DLLVM_ENABLE_WERROR=FALSE \
-DLLVM_TARGETS_TO_BUILD='AArch64' \
-DLLVM_DEFAULT_TARGET_TRIPLE='aarch64-apple-darwin20.1.0' \
-DDEFAULT_SYSROOT="$(xcrun --show-sdk-path)" \
-DLLVM_ENABLE_PROJECTS='clang;openmp;polly;clang-tools-extra;libcxx;libcxxabi' \
# -DLLVM_ENABLE_PROJECTS='clang;openmp;polly'
That gives a compiler that finds the right headers, but won't link successfully if OpenMP is used because it doesn't pass on any useful -L path or add a necessary rpath.
To overcome that I created a small shell script that sits in my ~/bin, at the front of my $PATH, which adds those extra linker flags.
#
# A truly awful hack, but it seems necessary.
# Install this with execute permissions as clang and clang++ in
# a directory early in your path, so that it is executed when clang or
# clang++ is needed.
#
# For brew...
INSTALLDIR=/usr/local/opt/llvm
# For a local build.
INSTALLDIR=${HOME}/software/clang-12.0.0/arm64/
# Find out the name of this file, and then invoke the same file in the
# compiler installation, adding the necessary linker directives
CMD=`echo $0 | sed "s/\/.*\///"`
${INSTALLDIR}/bin/${CMD} -L${INSTALLDIR}/lib -Wl,-rpath,${INSTALLDIR}/lib $*
I am not recommending this particularly; there should clearly be a better way to make it work, but it'll do for now, and lets me get back to using the compiler rather than building it!
I was able to build with -DDEFAULT_SYSROOT="$(xcrun --show-sdk-path)" -DCMAKE_INSTALL_PREFIX=/Users/foo/lokal/ and install into the lokal/bin lokal/lib path. Once that is done you can use LD_LIBRARY_PATH=/Users/foo/lokal/lib and all the libraries should be found without mucking with anything else rpath related.
I am trying to get exploded graph from one of the debug checkers called
debug.ViewExplodedGraph.
So I run command
clang -cc1 -analyze -analyzer-checker=debug.ViewExplodedGraph someprogram.c
It run successfully, but graph file no where to be found .
Where can we see the generated file?
I guess you should build the clang yourself. Then use the debug mode 'clang', call the command. The system clang is in release mode.
I use the system clang, it outputs nothing. But I use the clang that I build, it output something.
➜ bin ./clang -cc1 -analyze -analyzer-checker=debug.ViewExplodedGraph ~/Desktop/clang_test/test.c
Writing '/var/folders/_6/5wkxc9p92t94vdh0kyq2qyh40000gn/T/ExprEngine-9e6797.dot'... done.
Trying 'open' program... Remember to erase graph file: /var/folders/_6/5wkxc9p92t94vdh0kyq2qyh40000gn/T/ExprEngine-9e6797.dot
Warning: viewing graph requires assertions
➜ bin clang -cc1 -analyze -analyzer-checker=debug.ViewExplodedGraph ~/Desktop/clang_test/test.c
Warning: viewing graph requires assertions
cd to T folder
➜ T dot -Tsvg ExprEngine-9e6797.dot -o ~/Desktop/test.svg
then use chrome open test.svg
I would like to have complete Win32 development toolchain without Microsoft SDKs. mingw64 works, but its linker is very slow. As an alternative, I am trying to use clang for windows. I can get clang 7.0.1 (but not 8.0.0) work with mingw headers/libraries, however only using mingw's ld.exe. If I force ldd.exe to be used (-fuse-ld=lld), everything compiles and links fine, but the application immediately crashes when started. Is there anything I can do here, like change something in the commandline?
This is how commandline and --verbose for the link step looks like:
Linking...
clang++ -static -o "C:\upp\out\MyApps\CLANG.Debug.Debug_Full\main.exe"
-ggdb -L"C:\upp\bin/mingw64/64/x86_64-w64-mingw32/lib"
-L"C:\uppbin/mingw64/64/opt/lib" -L"C:\upp\bin/SDL2/lib/x64"
-L"C:\upp\bin/pgsql/x64/bin"
-L"C:\upp\bin/mysql/lib64"
-Wl,--stack,20000000 --verbose -target x86_64-pc-windows-gnu
-fuse-ld=lld
"C:/upp/out/MyApps/main/CLANG.Debug.Debug_Full.Main\main.o"
-Wl,--start-group -Wl,--end-group
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-pc-windows-gnu
Thread model: posix
InstalledDir: C:\xxx\LLVM2\bin
"C:\\xxx\\LLVM2\\bin\\ld.lld" -m i386pep -Bstatic
-o "C:\\upp\\out\\MyApps\\CLANG.Debug.Debug_Full\\main.exe"
"C:\\upp\\bin\\mingw64\\64\\x86_64-w64-mingw32\\lib\\crt2.o"
"C:\\upp\\bin\\mingw64\\64\\lib\\gcc\\x86_64-w64-mingw32\\8.1.0\\crtbegin.o"
"-LC:\\upp\\bin/mingw64/64/x86_64-w64-mingw32/lib"
"-LC:\\upp\\bin/mingw64/64/opt/lib"
"-LC:\\upp\\bin/SDL2/lib/x64" "-LC:\\upp\\bin/pgsql/x64/bin"
"-LC:\\upp\\bin/mysql/lib64"
"-LC:\\upp\\bin\\mingw64\\64\\lib\\gcc\\x86_64-w64-mingw32\\8.1.0"
"-LC:\\upp\\bin\\mingw64\\64\\x86_64-w64-mingw32\\lib"
"-LC:\\upp\\bin\\mingw64\\64\\lib"
"-LC:\\upp\\bin\\mingw64\\64\\x86_64-w64-mingw32/sys-root/mingw/lib"
--stack 20000000
"C:/upp/out/MyApps/main/CLANG.Debug.Debug_Full.Main\\main.o"
--start-group --end-group -lstdc++ --start-group -lmingw32
-lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32
-luser32 -lkernel32 --end-group
"C:\\upp\\bin\\mingw64\\64\\lib\\gcc\\x86_64-w64-mingw32\\8.1.0\\crtend.o"
The llvm-mingw toolchain is very easy to use and provides latest clang / libc++ / lld without any dependency on the Microsoft headers: https://github.com/mstorsjo/llvm-mingw
It links against the Microsoft ucrt and as such is compatible with MSVC-built DLLs (for the C API / ABI, not the C++ since it uses a different standard library implementation)
I'm using Ubuntu 14.04, after installing LLVM & Clang, when i tap this in the terminal it reports the error:
wishfay#wishfay-virtual-machine:~$ clang -v
clang: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by clang)
And i check my libstdc++.so.6:
wishfay#wishfay-virtual-machine:~$ locate libstdc++.so.6
/usr/lib/vmware-tools/lib32/libstdc++.so.6
/usr/lib/vmware-tools/lib32/libstdc++.so.6/libstdc++.so.6
/usr/lib/vmware-tools/lib64/libstdc++.so.6
/usr/lib/vmware-tools/lib64/libstdc++.so.6/libstdc++.so.6
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py
And my gcc version:
wishfay#wishfay-virtual-machine:~$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
And libstdc++.so.6:
wishfay#wishfay-virtual-machine:~$ strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_DEBUG_MESSAGE_LENGTH
I want to know how can i get the GLIBCXX_3.4.20 .
According to the ABI page, GLIBCXX_3.4.20 is part of gcc-4.9.
You need to upgrade your version of gcc, or get a clang binary that supports your OS, or you need to build clang from source.