Building a program with LLVM on Unix

Building LLVM itself involves Cmake, but what’s the best way to build a C++ program that needs to link with the LLVM libraries?

If you’re trying to optimise for making life as easy as possible for users and people creating binary packages, in the normal course of events, autotools is recommended. But the tutorial mentions running llvm-config to get things like library paths - does autotools know how to do this?

(I mostly use Windows, not as familiar with Unix, so please let me know if the question I’m asking is not quite the same as the question I should be asking.)

There are several m4 macros that let you write autoconf detection for
llvm. I recently needed to implement one. Have a look here:

https://github.com/google/autofdo/blob/master/m4/ax_llvm.m4

Diego.

I think that you’re answering your own question, almost. There are basically two approaches:

If you’re using CMake, then you can use the CMake LLVM modules to find the things that you need to link to. I’ve found this to be fairly fragile.

If you’re using any build system, then you can use llvm-config to find the LLVM version, CXXFLAGS, and LDFLAGS that are needed for your particular use. This is quite easy to do from any build system (from simple Makefiles to complex build system generators such as auto* and CMake).

David

Given that the LLVM API changes constantly, any reasonable C++ program may very well compile properly against only one specific version/release of LLVM. The probability that you can properly build against whatever some user has installed on some arbitrary system approaches zero.

If you accept this, then you likely work around it by configuring and installing an appropriate version of LLVM and its libraries yourself. At that point, you may just as well hard-code the path to what you’ve installed into your build system. Perhaps hard-code only the path to llvm-config, and bootstrap the rest from that.

When you say ‘configuring and installing an appropriate version of LLVM and its libraries yourself’ - that is indeed what I did on my own machine (Ubuntu 14.04 apt-get thinks 3.4 is latest, so I’m currently building 3.8 from source) - but how would you recommend doing this on a user’s machine?

If you’re shipping binaries, statically link. If you’re not, then it’s the packager’s problem. In the FreeBSD ports collection, we have every LLVM release from 3.5 onward as a dependency of something. They can all coexist happily. If LLVM were a bit better at stable APIs then we wouldn’t have, for example, Mesa only upgrading every few releases and requiring users to have at least two LLVM versions installed.

David

Thanks!

Bearing in mind that I don’t know m4, looking at the code, it seems to work by allowing an override to specify where to find llvm-config (which is the right thing to do, of course) but by default looking in the current path.

Based on both my own limited experience in the matter and what David Jones and David Chisnall are saying, one could argue that the path version probably will not be the correct one. That the correct default is actually more likely to be e.g. ~/llvm-3.8. Does that make sense?

That's a good question - should I ship binaries? I've picked up the idea
that if you want a Linux program of a version that isn't included in your
distro packages, you build from source, but it seems here that including a
binary in the tarball would do no harm, and perhaps save users some
trouble? It seems to make sense but be something not usually done, so I
figure I'd better check.

If the source is available and you have a vaguely sane release model (i.e. tarballs are available, dependencies are all on released versions of software), don’t ship binaries, just let the distributions worry about packaging it.

David