I'm trying to move a cross-compiled CMake project to Clang Modules to see whether compile time reduction is worth it. However, it seems that Clang is generating lots of duplicate modules in it's ModuleCache.
I'd like to figure out why (maybe some CMake config, etc), so I'm trying to run clang -module-file-info on the generated module files.
However, clang's output is just empty whenever I provide a proper module file. Am I doing anything wrong? Is there anything special that I need to take care of?
The files all have a reasonable size (from a few kB to a few MB), look fine in a Hex editor (start with CPCH, have some recognizable strings, etc) and whenever I specify a wrong file (or a file compiled with a different version of clang) I get the appropriate errors.
I've tried with clang 7.0.1 as well as 8.0.0.
I also tried --verbose but that didn't show any problems either.
To answer my own question:
clang doesn't output the stats on the command line, it puts it into a file by default written in the current directory.
Related
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.
I am compiling a fairly large library with many outside dependencies that I need to pull in. Each time I attempt a compilation I get a new error about a missing header file. I then have to go and track down where to find that header/library and add it to the project includes. This process of compilation-then-find-header/source is repeated and takes a lot of time.
I would like the compiler to continue trying to build and output all missing headers in one error list. Is this possible using Clang and if so how can I control it? On a related note, once I have all headers is it possible to tell Clang to report all linker errors/undefined references, so I don't have to repeat this process with source files?
I am looking for compiler flags to print out all possible errors (missing headers) and all undefined references. In other words, I want the compilation to continue passed the first file with errors and attempt to compile all files in the project. The compiler is Clang (C/C++) version 8.0.2. The make tool is ninja (1.5.3). Make files are generated with CMake (3.6.4).
Update:
Looking back, my original question was asking for a solution in the wrong tool. Instead of passing a flag to Clang, I needed to pass a flag to my make tool, Ninja.
From ninja --help:
-k N keep going until N jobs fail [default=1]
so i'd run ninja command like:
ninja -k 100
to continue until 100 errors are found or the build succeeds. One thing to note is that some errors may just stop the entire build if the erroneous file is necessary to continue the build process.
I'm producing dylibs with embedded bitcode and using the -bitcode-symbol-map flag to specify an output directory where files of the form UUID.bcsymbolmap get produced. I'd like to teach my build system about those bcsymbolmap files so I can install and package them, but it is hard to do so since the output name for the file is determined by the LC_UUID value in the dylib which seems to be determined by ld. It seems I have two choices:
Find a way to explicitly set the LC_UUID of the dylib when building it, so that I can predict the output name of the bcsymbolmap file.
Specify a well known name for the bcsymbolmap file (the -bitcode-symbol-map option does support this) which does not contain the UUID, and then at install time, figure out the LC_UUID of the associated dylib and rename the bcsymbolmap file appropriately.
However, I don't see either a linker flag that will let me specify the LC_UUID of the library when building it, or a tool to let me change it after the fact (thinking here of something like install_name_tool), nor do I see a utility that will easily give me back the LC_UUID of a given library (to do the needed renaming of the bcsymbolmap file), short of parsing the output of otool -l, which seems fragile and unpleasant.
I'd prefer to keep my options limited to things that ship with XCode. Does anyone know of tools to easily inject, edit, or emit the LC_UUID for a dylib?
Found something slightly better than parsing otool -l output: running dwarfdump -u on the target will list the UUIDs:
$ dwarfdump -u build/libfoo.dylib
UUID: BF8FAFCC-5B1F-3FC8-B2AF-FCDA16609D71 (arm64) build/libfoo.dylib
It still isn't ideal, but at least is trivial to parse with awk or similar.
Apple engineers, if anyone ever sees this, it would be very build system friendly to add an option to ld to explicitly set the LC_UUID at build time. The flag -no_uuid already exists, it would seem easy to add a -uuid flag that took a UUID as an argument and used that instead of generating one.
I have clang compiling and linking C and C++ code on my Windows system with no problems. Now I would like to view the AST for my files. In an older posting on this site the following command line was provided as a solution and it does actually display the AST for my file named test.c:
clang -cc1 -ast-dump test.c
There are two issues, however:
I searched the clang command line reference document but could find neither the -cc1 nor the -ast-dump option. Where are these documented?
I also found that any of the standard header files I included in my code, such as stdio.h, etc. were not found using the simple command line above (which was not a surprise). According to the clang command line reference document it seems I should be able to use the -I dir option in the standard way, such as
-I"C:\mingw64\lib\gcc\x86_64-w64-mingw32\5.1.0\include\ssp"
to provide clang with header file location information but that does not seem to work in this case even though header file stdio.h is there. I also tried the
-cxx-isystem directory
option but that didn't work either.
Is there some other document I should be looking at to find out how to do all of this correctly?
I installed boost using brew install boost in order to use odeint library (the odeint webpage says : odeint is a header-only library, no linking against pre-compiled code is required).
I am on Mac Yosemite 10.10.5 . Now when I cd to /usr/local/include, I can see boost directory there. Inside boost (/usr/local/include/boost) there are all the header files I needed for my project, along with the numeric/odeint directories needed for my specific purposes. At the same time, when I cd to usr\local\lib, I can see a lot of libboost_* .dylib and .a files.
However, when I try to compile a c++ file that I temporarily save in ~/Downloads (the first header is #include <boost/array.hpp>), I got the error fatal error: 'boost/array.hpp' file not found.
I am inexperienced in programming, and I really appreciate your help! Thank you!
Use the following include statements and let us know if it works.
#include <boost/numeric/odeint.hpp>
#include <boost/numeric/ublas/matrix.hpp>
If not, some additional info is needed. What is your BOOST version, what is the structure of the /usr/local/include/boost directory, how about including other (non-boost) headers from /usr/local/include (maybe compiler include path is broken).
I asked my professor about this. He gave very detailed explanation, and I think I should share so that everyone can benefit from it:
Theory:
Your compiler needs to know where these files are. You need to find a way to tell it where the files are.
Depending on how you are doing the compiling there will be different solutions. If you are compiling via the command line, use something like
g++ -I/usr/local/Cellar/boost
The -I stands for "include files". There is a similar g++ "switch" called -L for libraries when you get to that stage.
There is also a whole series of tools to tell the compiler how to search for include files. The directory /usr/local/include is almost certainly on the list of places for it to look.
If you are using "make" and the associated tools for compiling, you can add the include directories to part of the "Makefile". Again, the details are different for every setting.
Bottom line -- you'll need to learn more about your compiler system. Find manuals and examples for your specific tools and system. Learn how those tools work and where to specify the boost libraries. Read the boost manuals and learn where they store files and what all the names are for the different directories where these files are stored.
It's not fun work, but it is worthwhile learning about how all the parts get put together.