Clang Build Errors - c++

I am trying to build clang trunk on Ubuntu 16.04 and I am having build errors no matter what I try. First I built llvm/clang/libc++/libc++abi against gcc 5.4, this worked fine. Now I am trying to use the clang I just build to rebuild llvm/clang/libc++/libc++abi. This fails with the following error message:
[162/4396] Linking CXX executable bin/llvm-tblgen FAILED:
: && /usr/local/bin/clang++ -stdlib=libc++
-fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers
-pedantic -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-Werror=date-time -std=c++11 -fcolor-diagnostics
-ffunction-sections -fdata-sections -O3 -DNDEBUG
-lc++ -lc++abi -Wl,-allow-shlib-undefined
-Wl,-O3 -Wl,--gc-sections
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmWriterEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmWriterInst.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/Attributes.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CallingConvEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeEmitterGen.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenDAGPatterns.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenInstruction.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenMapTable.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenRegisters.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenSchedule.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CodeGenTarget.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DAGISelEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherGen.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcherOpt.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DAGISelMatcher.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DFAPacketizerEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DisassemblerEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/FastISelEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/FixedLenDecoderEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/InstrInfoEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/IntrinsicEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/OptParserEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/PseudoLoweringEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/RegisterInfoEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/SearchableTableEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/SubtargetEmitter.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/TableGen.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86DisassemblerTables.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86ModRMFilters.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/X86RecognizableInstr.cpp.o
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/CTagsEmitter.cpp.o
-o bin/llvm-tblgen
lib/libLLVMSupport.a
lib/libLLVMTableGen.a
-lpthread
lib/libLLVMSupport.a
-lrt
-ldl
-ltinfo
-lpthread
-lz
-lm
lib/libLLVMDemangle.a
-Wl,-rpath,"\$ORIGIN/../lib" &&
: utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/DFAPacketizerEmitter.cpp.o: In function `(anonymous namespace)::DFAPacketizerEmitter::run(llvm::raw_ostream&)': /home/mehrlich/Code/llvm/llvm/utils/TableGen/DFAPacketizerEmitter.cpp:(.text._ZN12_GLOBAL__N_120DFAPacketizerEmitter3runERN4llvm11raw_ostreamE+0x253f): undefined reference to `std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>::~basic_string()' clang-4.0: error: linker command failed with exit code 1 (use -v to see invocation) [162/4396] Building CXX object lib/MC/CMakeFiles/LLVMMC.dir/MCContext.cpp.o ninja: build stopped: subcommand failed.
The relevant error being the undefined symbol:
In function (anonymous namespace)::DFAPacketizerEmitter::run(llvm::raw_ostream&)': /home/mehrlich/Code/llvm/llvm/utils/TableGen/DFAPacketizerEmitter.cpp:(.text._ZN12_GLOBAL__N_120DFAPacketizerEmitter3runERN4llvm11raw_ostreamE+0x253f): undefined reference to std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>::~basic_string()'
Presumably this is for one of two reasons:
1. Clang is using libstdc++ headers:
We can see from the failing command that clang++ picks up the -stdlib=libc++ switch correctly. Running % clang++ --stdlib=libc++ -E -x c++ - -v < /dev/null to inspect the default include paths with this options gives
clang version 4.0.0 (trunk 281213) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Candidate multilib: .;#m64 Selected multilib: .;#m64 Found CUDA installation: /usr/local/cuda, version 7.5 "/usr/local/bin/clang-4.0" -cc1 -triple x86_64-unknown-linux-gnu -E -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name - -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir /usr/local/bin/../lib/clang/4.0.0 -internal-isystem /usr/local/bin/../include/c++/v1 -internal-isystem /usr/local/include
-internal-isystem /usr/local/bin/../lib/clang/4.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /home/mehrlich/Code/llvm/build -ferror-limit 19 -fmessage-length 343
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o - -x c++ - clang -cc1 version 4.0.0 based upon LLVM 4.0.0svn default target x86_64-unknown-linux-gnu ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here: /usr/local/bin/../include/c++/v1 /usr/local/include /usr/local/bin/../lib/clang/4.0.0/include /usr/include/x86_64-linux-gnu /usr/include End of search list.
# 1 "<stdin>"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 328 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "<stdin>" 2
The first header search path #include <...> search starts here: /usr/local/bin/../include/c++/v1 is the correct location of libc++ headers. So I highly doubt it is this
2. Clang is not linking against libc++
Adding the options -lc++ -lc++abi to CMAKE_EXE_LINKER_FLAGS, CMAKE_SHARED_LINKER_FLAGS, CMAKE_MODULE_LINKER_FLAGS, and CMAKE_STATIC_LINKER_FLAGS gives this following error:
[65/4396] Linking CXX static library lib/libLLVMDemangle.a
FAILED: : && /usr/bin/cmake -E remove lib/libLLVMDemangle.a && /usr/bin/ar qc lib/libLLVMDemangle.a -lc++ -lc++abi lib/Demangle/CMakeFiles/LLVMDemangle.dir/ItaniumDemangle.cpp.o && /usr/bin/ranlib lib/libLLVMDemangle.a && :
/usr/bin/ar: invalid option -- '+'
Usage: /usr/bin/ar [emulation options] [-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin <name>] [member-name] [count] archive-file file...
/usr/bin/ar -M [<mri-script]
commands:
d - delete file(s) from the archive
m[ab] - move file(s) in the archive
p - print file(s) found in the archive
q[f] - quick append file(s) to the archive
r[ab][f][u] - replace existing or insert new file(s) into the archive
s - act as ranlib
t - display contents of archive
x[o] - extract file(s) from the archive
command specific modifiers:
[a] - put file(s) after [member-name]
[b] - put file(s) before [member-name] (same as [i])
[D] - use zero for timestamps and uids/gids (default)
[U] - use actual timestamps and uids/gids
[N] - use instance [count] of name
[f] - truncate inserted file names
[P] - use full path names when matching
[o] - preserve original dates
[u] - only replace files that are newer than current archive contents
generic modifiers:
[c] - do not warn if the library had to be created
[s] - create an archive index (cf. ranlib)
[S] - do not build a symbol table
[T] - make a thin archive
[v] - be verbose
[V] - display the version number
#<file> - read options from <file>
--target=BFDNAME - specify the target object format as BFDNAME
optional:
--plugin <p> - load the specified plugin
emulation options:
No emulation specific options
/usr/bin/ar: supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 a.out-i386-linux pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big pe-x86-64 pe-bigobj-x86-64 pe-i386 plugin srec symbolsrec verilog tekhex binary ihex
And we can see for this, that the linker options are being passed to /usr/bin/ar by cmake for static libraries (this seems like the wrong thing to do to me but I am not an expert in build processes so I might be wrong). Removing these options from CMAKE_STATIC_LINKER_FLAGS reverts to the original error message about undefined symbols, so presumably the llvm-tblgen target is a static library. llvm-tblgen is definitely an executable, not sure the CMAKE_EXE_LINKER_FLAGS are not being applied to it flags are being applied, which means I have no idea why this would not be working...
At this point I'm not sure who's fault this is, mine, clang, or cmake, but if anyone has any advice or expertise in doing this process, I'd appreciate the help.
Update
Now errors are in compiler-rt:
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/sanitizer_unwind_linux_libcdep.cc.o: In function `__sanitizer::Unwind_GetIP(_Unwind_Context*)':
/home/mehrlich/Code/llvm/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:98: undefined reference to `_Unwind_GetIP'
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/sanitizer_unwind_linux_libcdep.cc.o: In function `Unwind_GetIP':
/home/mehrlich/Code/llvm/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:98: undefined reference to `_Unwind_GetIP'
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/sanitizer_unwind_linux_libcdep.cc.o: In function `__sanitizer::BufferedStackTrace::SlowUnwindStack(unsigned long, unsigned int)':
/home/mehrlich/Code/llvm/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:125: undefined reference to `_Unwind_Backtrace'
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.x86_64.dir/sanitizer_unwind_linux_libcdep.cc.o: In function `SlowUnwindStack':
/home/mehrlich/Code/llvm/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_unwind_linux_libcdep.cc:125: undefined reference to `_Unwind_Backtrace'
Seems related to this bug

This was caused by a recent bug in libc++ which accidentally removed the definition of ~basic_string() from versions of libc++.so built with GCC. The bug was introduced September 9th and I fixed it earlier today.
Unfortunately your libc++ installation is buggy and it will need to be updated before building Clang. You can simply install a new libc++ over top of the existing installation. This can probably be done using sudo make install-cxx from your current (buggy) build directory. Then you can continue building Clang as normal.
For more info about building/installing libc++ see http://libcxx.llvm.org/docs/BuildingLibcxx.html.
(Note: Fixing the libc++ installation should not require rebuilding LLVM or Clang.)

Related

Clang on MacOS having problems with its includes

I have built from scratch Clang on MacOS and I am having problems with it.
Used following to configure Clang for building:
cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/opt/clang-12 -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD="AArch64;ARM;X86" -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;lldb" ../llvm
This is my test program:
#include <ostream>
#include <algorithm>
int main(int argc, char** argv) {
return 0;
}
OK if compiled with Clang 11.0.3 that ships with XCode clang++ -c test.cc
ERROR if using new Clang 12 (built) /opt/clang-12/bin/clang++ -c test.cc
In file included from test.cc:2:
In file included from /opt/clang-12/bin/../include/c++/v1/ostream:138:
In file included from /opt/clang-12/bin/../include/c++/v1/ios:214:
In file included from /opt/clang-12/bin/../include/c++/v1/iosfwd:95:
/opt/clang-12/bin/../include/c++/v1/wchar.h:119:15: fatal error: 'wchar.h' file not found
#include_next <wchar.h>
^~~~~~~~~
1 error generated.
Depending on what I am trying to include I get different include errors.
➜ tests /opt/clang-12/bin/clang++ -v -c test.cc
clang version 12.0.0 (https://github.com/llvm/llvm-project.git b529c5270c99e0ca18e3cbd9a5f50eb0970e560a)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /opt/clang-12/bin
(in-process)
"/opt/clang-12/bin/clang-12" -cc1 -triple x86_64-apple-macosx10.15.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cc -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-rounding-math -munwind-tables -fcompatibility-qualified-id-block-type-checking -target-cpu penryn -debugger-tuning=lldb -target-linker-version 556.6 -v -resource-dir /opt/clang-12/lib/clang/12.0.0 -stdlib=libc++ -internal-isystem /opt/clang-12/bin/../include/c++/v1 -internal-isystem /usr/include/c++/v1 -internal-isystem /usr/local/include -internal-isystem /opt/clang-12/lib/clang/12.0.0/include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /Users/duddie/Projects/Audio/1voct/1voct_modular/tests -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcolor-diagnostics -o test.o -x c++ test.cc
clang -cc1 version 12.0.0 based upon LLVM 12.0.0git default target x86_64-apple-darwin19.6.0
ignoring nonexistent directory "/usr/include/c++/v1"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/clang-12/bin/../include/c++/v1
/usr/local/include
/opt/clang-12/lib/clang/12.0.0/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
In file included from test.cc:2:
In file included from /opt/clang-12/bin/../include/c++/v1/ostream:138:
In file included from /opt/clang-12/bin/../include/c++/v1/ios:214:
In file included from /opt/clang-12/bin/../include/c++/v1/iosfwd:95:
/opt/clang-12/bin/../include/c++/v1/wchar.h:119:15: fatal error: 'wchar.h' file not found
#include_next <wchar.h>
^~~~~~~~~
1 error generated.
ERROR if Clang 11.0.3 (XCode) or Clang 12 but target for ARM clang++ -target arm-none-eabi -c test.cc
test.cc:2:10: fatal error: 'ostream' file not found
#include <ostream>
^~~~~~~~~
1 error generated.
Any ideas what am I doing wrong?
Add the following to the shell profile file ~/.bash_profile or ~/.zsh_profile or any other way to set environment variable accessible to the shell you're running it in.
export SDKROOT="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk"
Verify the correct path to the SDK on your macOS/Xcode version.
Reopen Terminal (sourcing the file may not work reliably).
Then try your compile command again.
/opt/clang-12/bin/clang++ -c test.cc
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. The command line tools will search the
SDK for system headers by default. However, some software may fail to
build correctly against the SDK and require macOS headers to be
installed in the base system under /usr/include. If you are the
maintainer of such software, we encourage you to update your project
to work with the SDK or file a bug report for issues that are
preventing you from doing so. As a workaround, an extra package is
provided which will install the headers to the base system. In a
future release, this package will no longer be provided. You can find
this package at:
/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
https://developer.apple.com/documentation/xcode-release-notes/xcode-10-release-notes
Probably a more portable one (I found the hint at llvm-project/llvm/utils/lit/lit/util.py:399):
export SDKROOT=$(xcrun --show-sdk-path --sdk macosx)
Also, you can also add -isysroot argument to clang driver to alter the default system root for header searching:
clang++ a.cpp -isysroot $(xcrun --show-sdk-path --sdk macosx)
More details and investigation notes here
For what it's worth, I was able to fix the problem with MacOs Big Sur by doing
export SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk'

Compile LLVM from sources on macOS Catalina (How to solve "stdio.h" not found)

I'm bringing to your attention a question I tackled with for a few days and no issue could solve for me, in the hope that it'll save some other people time.
I try to compile LLVM from sources on macOS Catalina (10.15).
To do so, I used the following commands (after following the LLVM build manual):
git clone https://github.com/llvm/llvm-project
cd llvm-project
mkdir build && cd build
cmake -G "Ninja" -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DCMAKE_BUILD_TYPE="Debug" ../llvm
ninja
Now you should have a working clang compiler under build/bin.
However, given /tmp/program.c with this contents:
#include <stdio.h>
int main() {
printf("Hello, world!\n");
return 0;
}
I got the following output:
/tmp/program.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^~~~~~~~~
1 error generated.
I tried a lot of solutions, including setting CPATH, CFLAGS, CXXFLAGS, LDFLAGS etc but none worked.
System headers new path
Since macOS Catalina, the /usr folder is been mounted as a read-only directory, so even as a root - no one has permission to modify this folder (well, unless you reboot in SIP mode, which's obviously not a considerable solution).
The entire toolchain is saved by default under /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk. You can get your path by executing xcrun --show-sdk-path. I'll assume that you do have the default path in my answer but please adjust as needed.
Gathering information
Running clang with the -v flag gave me the following:
./clang /tmp/program.c -v --
clang version 11.0.0 (https://github.com/llvm/llvm-project 01641197ee0bd3895c756c925723c8c8e03bcb09)
Target: x86_64-apple-darwin19.5.0
Thread model: posix
InstalledDir: ~/llvm/llvm-project/build/bin/.
"~/llvm/llvm-project/build/bin/clang-11" -cc1 -triple x86_64-apple-macosx10.15.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free -main-file-name program.c -mrelocation-model pic -pic-level 2 -mframe-pointer=all -fno-rounding-math -munwind-tables -fcompatibility-qualified-id-block-type-checking -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb -target-linker-version 556.6 -v -resource-dir ~/llvm/llvm-project/build/lib/clang/11.0.0 -internal-isystem /usr/local/include -internal-isystem ~/llvm/llvm-project/build/lib/clang/11.0.0/include -internal-externc-isystem /usr/include -fdebug-compilation-dir ~/llvm/llvm-project/build/bin -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fmax-type-align=16 -fcolor-diagnostics -o /var/folders/64/6bf82c_52ws1n4cwc376znvr0000gn/T/program-d111a4.o -x c /tmp/program.c
clang -cc1 version 11.0.0 based upon LLVM 11.0.0git default target x86_64-apple-darwin19.5.0
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
~/llvm/llvm-project/build/lib/clang/11.0.0/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
/tmp/program.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^~~~~~~~~
1 error generated.
Which can teach us that our include paths for system headers are:
/usr/local/include
~/llvm/llvm-project/build/lib/clang/11.0.0/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
Hence, we can see that the location of the new headers (/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk) doesn't appear here and thus the error.
We could do a symbolic link from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk to /usr/local/include, but that'd create conflicting headers and have bad side effects (yes, I tried. Yes, it was very stupid...).
Solution
We can see that one of the default search headers path appears under the build directory (~/llvm/llvm-project/build/lib/clang/11.0.0/include). Symbolic-linking the standard headers to this directory won't create any dangerous conflicts.
Hence, all you need to do to solve this issue, is:
ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/* ~/llvm/llvm-project/build/lib/clang/11.0
I hope that my answer will help others who struggle with this issue.
To be able to use clang compiled from LLVM sources on macOS, you can do the following:
Set PATH to include the bin directory where the newly built clang is located.
New clang needs to know where XCode SDK is located. You can do this by setting SDKROOT environment variable. For example:
SDKROOT=`xcrun --show-sdk-path` clang test.c
That should be it.

Boost no longer works with Homebrew on Mac El Capitan

I just updated from Yosemite to El Capitan and it has broken one of my C++ programs which was relying on Boost. Whenever I try to compile, I get these errors:
fatal error: 'boost/timer/timer.hpp' file not found
#include <boost/timer/timer.hpp>
fatal error: 'boost/program_options.hpp' file not found
#include "boost/program_options.hpp"
I've been compiling it with the correct flags and it worked perfectly before:
-lboost_timer-mt \
-lboost_program_options-mt \
I've followed the home-brew instructions to chown /usr/local, run brew doctor and brew update, even brew reinstall boost. I've also checked and timer.hpp is present in /usr/local/include/boost.
Update Ran: clang++ -E -x c++ - -v < /dev/null
Apple LLVM version 7.0.0 (clang-700.0.72) Target: x86_64-apple-darwin15.0.0 Thread model: posix "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1 -triple x86_64-apple-macosx10.11.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -disable-llvm-verifier -main-file-name - -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 253.2 -v -dwarf-column-info -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.0.0
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
-stdlib=libc++ -fdeprecated-macro -fdebug-compilation-dir /usr/local/lib -ferror-limit 19 -fmessage-length 272 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.11.0
-fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o - -x c++ - clang -cc1 version 7.0.0 based upon LLVM 3.7.0svn default target x86_64-apple-darwin15.0.0 ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/v1" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/local/include" ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/7.0.0/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks (framework directory) End of search list.
# 1 "<stdin>"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 332 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "<stdin>" 2
You should install the Xcode Command Line tools with xcode-select --install to get a version of clang that searches /usr/local by default. Otherwise, you're using the versions provided by Xcode proper, which only search the OS X SDK paths. (/usr/bin/gcc and /usr/bin/g++ both invoke clang and are not actually versions of gcc.)
I had the same problem when I upgraded to El Capitan. I solved this problem reinstalling Boost with brew.
If you don't have brew installed, you can install it with
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Then, install boost
brew install boost

Clang on Windows fails to compile code

I built the LLVM and Clang (version 3.2) on Windows with the help of CMake and MinGW. The building is easy and successful. However, Clang failed to work with the sample code.
#include <stdarg.h>
#include <stdio.h>
int main()
{
printf("BAD: %lld\n", 1);
return 0;
}
When I compiled it with clang as
clang -o printf.exe printf.c -v
On Windows, it failed with messages
clang version 3.2 (branches/release_32 172788)
Target: i686-pc-mingw32
Thread model: posix
"D:/llvm/Build/bin/clang.exe" -cc1 -triple i686-pc-mingw32 -S -disable-free -main-file-name printf.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -mconstructor-aliases -target-cpu pentium4 -momit-leaf-frame-pointer -v -resource-dir "D:/llvm/Build/bin\\..\\lib\\clang\\3.2" -fmodule-cache-path "C:\\Users\\usrname\\AppData\\Local\\Temp\\clang-module-cache" -fno-dwarf-directory-asm -ferror-limit 19 -fmessage-length 140 -mstackrealign -fno-use-cxa-atexit -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o C:/Users/usrname/AppData/Local/Temp/printf-976141.s -x c printf.c
clang -cc1 version 3.2 based upon LLVM 3.2svn default target i686-pc-mingw32
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "D:/llvm/Build/bin/../lib/clang/3.2/../../../i686-w64-mingw32/include"
ignoring nonexistent directory "D:/llvm/Build/bin/../lib/clang/3.2/../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include search starts here:
D:/llvm/Build/bin/../lib/clang/3.2/include
D:/llvm/Build/bin/../lib/clang/3.2/../../../include
c:/mingw/include
End of search list.
printf.c:6:24: warning: format specifies type 'long long' but the argument has type 'int' [-Wformat]
printf("BAD: %lld\n", 1);
~~~~ ^
%d
1 warning generated.
"C:/MinGW/bin/gcc.exe" -v -c -m32 -o C:/Users/usrname/AppData/Local/Temp/printf-976142.o -x assembler C:/Users/usrname/AppData/Local/Temp/printf-976141.s
Using built-in specs.
COLLECT_GCC=C:/MinGW/bin/gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.1/configure --enable-languages=c,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-m32' '-o' 'C:/Users/usrname/AppData/Local/Temp/printf-976142.o' '-mtune=i386' '-march=i386'
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/as.exe -o C:/Users/usrname/AppData/Local/Temp/printf-976142.o C:/Users/usrname/AppData/Local/Temp/printf-976141.s
C:/Users/usrname/AppData/Local/Temp/printf-976141.s: Assembler messages:
C:/Users/usrname/AppData/Local/Temp/printf-976141.s:7: Error: bad expression
C:/Users/usrname/AppData/Local/Temp/printf-976141.s:7: Error: junk at end of line, first unrecognized character is `\'
clang: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation)
The generated temporary assemble file is:
.def _main;
.scl 2;
.type 32;
.endef
.text
.globl _main
.align 16, 0x90, "\357\276\255\336"
_main:
It seems that Clang on Windows generats a wrong format assemble file.
But on Linux, it generats an obejct file directly instead of an assemble file and succeeds to compile.
How can I fix this problem? Thanks very much!
There is something wrong with your installation.
Please find my Clang builds here:
Clang package and required GCC package.
As shown in the Clang package download directory, extract both to the same directory, and add "mingw32-dw2/bin" to PATH. I tested you code and it works.
Note your code has an error:
#include <stdarg.h>
#include <stdio.h>
int main()
{
printf("BAD: %lld\n", 1LL); // NOTE the suffix specifying "long long"
return 0;
}
Observe the line of the failing invocation
"C:/MinGW/bin/gcc.exe" -v -c -m32 -o C:/Users/usrname/AppData/Local/Temp/printf-976142.o -x assembler C:/Users/usrname/AppData/Local/Temp/printf-976141.s
clang defaults to AT&T syntax and not Intel, if I read the docs correctly. For your version of gcc the arguments may require looking into for missing/incorrect ones. If running successful build has priority then alternatively try compiling to .o, then linking to be an exe with llvm's lld first, and then gnu's ld second.

build svn clang with stdlibc++ 4.7

I am new to compile clang directly from svn. I want to build clang against stdlibc++4.7.
My system is running Mac OS mountain lion 10.8, so I used MacPorts to install gcc47. Now the library is in /opt/local/lib/gcc47 and headers are in /opt/local/include/gcc47.
I downloaded clang from svn and followed the guide from: http://clang.llvm.org/get_started.html
how do i specify clang configure to use stdlibc++ 4.7? It mentions in the guide that i should specify it using --with-gcc-toolchain. What exactly should I use with --with-gcc-toolchain? is it just ../configure --with-gcc-toolchain
I also tried to compile gcc from svn and install it into my home directory as $HOME/gcc. And then pass configure with --with-gcc-toolchain=PATH_TO_GCC_IN_HOME_DIR. After compilation, and tried the following:
./clang -v -x c++ /dev/null -fsyntax-only
it still shows linked with gcc4.2 lib that came with Mac OS:
clang version 3.2 (trunk 161295)
Target: x86_64-apple-darwin12.0.0
Thread model: posix
"/Users/chen/Repository/build/Debug+Asserts/bin/clang" -cc1 -triple x86_64-apple-macosx10.8.0 -fsyntax-only -disable-free -main-file-name null -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 128.2 -v -resource-dir /Users/chen/Repository/build/Debug+Asserts/bin/../lib/clang/3.2 -fmodule-cache-path /var/folders/1l/m5km38_d3lxbrvysgv6s42680000gn/T/clang-module-cache -fdeprecated-macro -fdebug-compilation-dir /Users/chen/Repository/build/Debug+Asserts/bin -ferror-limit 19 -fmessage-length 145 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -x c++ /dev/null
clang -cc1 version 3.2 based upon LLVM 3.2svn default target x86_64-apple-darwin12.0.0
ignoring nonexistent directory "/usr/include/c++/4.2.1/i686-apple-darwin10/x86_64"
ignoring nonexistent directory "/usr/include/c++/4.0.0"
ignoring nonexistent directory "/usr/include/c++/4.0.0/i686-apple-darwin8/"
ignoring nonexistent directory "/usr/include/c++/4.0.0/backward"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/Users/chen/Repository/build/Debug+Asserts/bin/../lib/clang/3.2/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
How can I compile clang with libstdc++ 4.7?
Thanks,