I've been trying to make the switch to LLVM, since I'd like to get more into the whole 'software-dev' scene, and it seems like right now, LLVM is the future. I built LLVM/Clang/LLD/compiler-rt/libcxx from source several times now, both with GNU/GCC and LLVM/Clang.
The problem appears when I try to use the newly compiled compilers. From what I can see, clang is using GNU ld rather than LLVM's lld. Is this true?
LLD seems to be a very limited program from the lld -help output, but from what I have read, it is as full featured as ld. I cannot find documentation on how to use it anywhere -- does anyone know where I can find some kind of comprehensive manual on it?
Thank you.
Pass -fuse-ld=lld to clang to make it use lld for linking. By now, it's in very good shape.
You can pass -v or -### to clang to make it print which linker command it runs or would run.
There's no manual for the moment and depending on platform may work well enough for you. That said, if lld were "production ready" we'd have switched clang to using it by default for the various platforms. It's not there yet so I wouldn't suggest you use it for your day to day development.
The LLVM team say that is production ready because FreeBSD can compile and link a lot of things with LLD.
The documentation on the LLD project can be found on http://lld.llvm.org/.
It's written :
LLD is a drop-in replacement for the GNU linkers.
That accepts the same command line arguments and linker scripts as GNU.
So you can use same arguments than GNU LD.
I know this question is old, but there is a newer solution to it:
To use the ld.lld linker when building any llvm target, just pass -DLLVM_ENABLE_LLD=ON in the commandline to cmake.
//Use lld as C and C++ linker.
LLVM_ENABLE_LLD:BOOL=TRUE
For other cmake projects, pass: -DCMAKE_LINKER=/etc/bin/ld.lld
Related
At work, I work on a C++ program which uses Cmake. In the top-level CMakeLists.txt, the CMAKE_CXX_FLAGS_DEBUG flag is set for Clang to input the different flags we want for the compilation.
My problem is that I see previous developers on the project put a lot of compilation options I don't understand for clang and I don't find them in the documentation... I don't understand why they aren't documented ! Moreover, I really wonder how the previous developers had the idea to put them in the code if they couldn't find them in the official documentation !
Here is a few examples of flags I couldn't find in the documentation :
-Wno-covered-switch-default
-Wno-exit-time-destructors
-Wno-padded
-Wweak-vtables
I am trying to get LLVM IR for a file which is linked with some static libararies.
I tried to link using llvm-link . It just copy the .bc files in one file ( not like native linking).
clang -L$(T_LIB_PATH) -lpthread -emit-llvm gives an error: emit-llvm can not be used with linking. When passing -c option, it gives warning that the linking options were not used.
My main goal is to get .bc file with all resolved symbols and references. How can I achieve that with clang version 3.4.?
You may have a look at wllvm. It is a wrapper on the compiler, which enable to build a project and extract the LLVM bitcode of the whole program.
You need to use wllvm and wllvm++ for C and C++, respectively (after setting some environment variables).
Some symbols come from source code via LLVM IR. IR is short for intermediate representation. Those symbols are easy to handle, just stop in the middle of the build process.
Some others come from a library and probably were generated by some other compiler, one that never makes any IR, and in any case the compiler was run by some other people at some other location. You can't go back in time and make those people build IR for you, even if their compiler has the right options. All you can do is obtain the source code for the libraries and build your entire application from source.
Do you guys know why the AddressSanitizer would be taking a whole different set of libraries.
For instance, I was trying to recreate strcmp, when I was comparing my output with the standard strcmp from string.h but what I realized is that compiling it normally with gcc it outputs the difference, but with the -fsanitize=address flag added it gives me 1, 0, -1 outputs.
both gcc and clang behave the same way
I am on a OSX 10.11.6, btw.
Is this behavior unique to MACOS or other systems have similar effects?
Btw, from what I was reading, the strcmp of the GNU C library outputs the difference and the Apple version only has outputs of 1, -1 and 0.
So this is even more puzzling to me, because the gcc/clang in MACOS seems to be using the gnu libc by default, and somehow shifting to the apple's version of libc when using the -fsanitize=address flag.
If anyone can explain this to me I would very grateful.
btw, just in case, this is my configuration of gcc:
➜ gcc --version
Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.38)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
-fsanitize=address forces your binary to link against Asan runtime which overloads a lot of standard functions (including strcmp). Overloading is done to check input arguments to these functions. Asan implementations are generally standard-compliant but don't follow all the nits for a particular platform so this may be the reason for differences that you see.
I have a ModulePass that's working with the opt tool, but I'm having trouble figuring out how to make it available to clang at the command line. My current workflow for using my pass is:
clang -c -emit-llvm [c-source code files]
llvm-link [llvm bitcode files]
opt -load [PassName].so -[pass-name] [linked llvm file]
llc [resulting bitcode file]
gcc [resulting assembler file] -o [target]
I would like to get my pass integrated with the clang command line so that it could be invoked as part of the build of existing software (e.g. c++ standard library) without having to remake the whole build system for each thing I compile. I've seen hints about how to do this, but I haven't been able to put the pieces together into a working setup.
Run an LLVM Pass Automatically with Clang describes exactly what I want, but the method appears to be deprecated in LLVM 3.4 (PassManagerBuilder has been moved to the legacy namespace).
LLVM - Run Own Pass automatically with clang seems to address the basic issue, but I was hoping I could do this without having to modify clang (which seems to be what's suggested there).
What is the best way to make a new pass available from clang using LLVM 3.4?
Clang still uses PassManagerBuilder as of 3.5 (see the PassManagerBuilderWrapper class in BackendUtil.cpp). So I believe extending it with RegisterStandardPasses, as in my blog post, is still the only way to add a pass to Clang's pass manager.
It's frustratingly difficult to find any information about how deprecated the "old" pass manager infrastructure is. But since Clang is still using it, it can't be that deprecated. :)
OpenMPI strongly recommends using their wrapper compilers. Behind the scenes, their wrapper compiler mpiCC calls gcc (by default?) and adds the necessary flags for MPI code to compile. However, other compilers give more descriptive error messages than gcc (e.g. clang which is also GCC-compatible). So, I'd like to be able to use clang with Open MPI.
I tried:
1) finding an mpiCC option for specifying the compiler, but
mpiCC --help
just spits out the g++ help page.
2) using the --showme:compile option
mpiCC --showme:compile ./test-boost.cc -lboost_mpi -lboost_serialization -o test-boost
which, instead of calling gcc, prints the flags needed for compiling the MPI code. I can then use those with clang (since it's GCC-compatible). This should work, but I'm looking for an easier solution.
Open MPI FAQ says which environmental variables can be set to override the default choice of the compiler called by the wrapper.
http://www.open-mpi.org/faq/?category=mpi-apps#override-wrappers-after-v1.0
Depending on the version of OpenMPI you should set OMPI_CXX=clang++ or OMPI_MPICC=clang. For OpenMPI v.1.1 and later use OMPI_CXX and then call the wrapper compiler. The wrapper would call clang++ in turn.
Setting OMPI_CC=clang or OMPI_CXX=clang++ as environment variables in .bashrc, as described in the official FAQ of OpenMPI, is NOT working for me. I have to attach them ahead whenever I use mpicc, e.g.
OMPI_CC=clang mpicc --showme:command
So in Makefile, I set CC=OMPI_CC=clang mpicc, which works well for me.