LLVM building problem

Dear all,

I’m using a Virtual Machine with Ubuntu 18.04 at VIrtualBox and I’m trying to build the LLVM project from https://github.com/llvm/llvm-project.git.

This VM has 6 cores (from an intel core i-7 8th gen), 11GB of RAM and 300GB of storage (from a 1TB HDD) at a laptop, this is the model: MSI GS63 Stealth 8RE.

Then, I’m doing exactly that this tutorial says to build LLVM: https://llvm.org/docs/GettingStarted.html

  1. Clone the project from git: “git clone https://github.com/llvm/llvm-project.git”.
  2. Use cmake at the build directory: “cmake -G ‘Ninja’ …/llvm”.
  3. Build the project with ninja: “ninja” (i do not use any flag).

It seems to build well until i reach the final part, where the build try to link CXX executables. At this point, the VM freeze and I cannot do anything. I also have tried to expand the SWAP memory creating a second swap file with 90GB and the VM also freeze.

I have tried this like 20 times and I don’t know why this happens, it seems impossible to build this project. If you have any suggestions, please reply this post.

Thanks in advance.

Hi Enrique
There are many options you can set while building the LLVM.
Given your system features, you can do a release build of llvm. Default one is debug build, you have to change this to release build.

This will result in smaller libraries hence you can complete the linking process.


Try adding -D LLVM_PARALLEL_LINK_JOBS=1 to your CMake command line. The problem is that ninja will likely start 12 (on your system at least) link jobs at the same time, since these tend to bunch together. That will rapidly exhaust almost any machine's memory.

If -D LLVM_PARALLEL_LINK_JOBS=1 works, you can try increasing it bit by bit until the memory usage is acceptable.

And yes, this setting should most likely be a default... :slight_smile:


I also recommend making sure that you're using the gold linker. AFAIK
Ubuntu defaults to BFD. Gold is much more memory efficient. LLD would be
even better.

Most likely ld on your system is a symlink to the actual linker binary.
Just check what it points to (I suspect that it's going to be ld.bfd or
something similar) and update accordingly (e.g. to ld.gold).

Hope this helps.


+1 to what other folks have already said (reducing the parallel link jobs, using gold or lld and not binutils/bfd ld) - but also/alternatively/in addition you can use Split DWARF (there’s an LLVM CMake option for this (just search CMakeCache for “SPLIT” and you should be able to find it)) that’ll reduce the link size of debug info binaries.