The change in bug #151559 doesn't work for current versions of llvm on all platforms, and it won't work on platforms that don't use the .so file extension (eg: OS X and Windows) The macro is doing: set(LLVM_SONAME "LLVM-${LLVM_VERSION}") if (EXISTS "${LLVM_LIBS_DIRECTORY}/lib${LLVM_SONAME}.so") set(LLVM_LIBRARIES "${LLVM_LDFLAGS} -l${LLVM_SONAME}") else () set(LLVM_LIBRARIES "${LLVM_LDFLAGS} ${LLVM_LIBS}") endif () Recent versions of llvm don't include "-${LLVM_VERSION}" in the name of the library. On OS X, the library is named libLLVM-${LLVM_VERSION}.dylib for llvm 3.7 and earlier and libLLVM.dylib for llvm 3.8 (release_38 branch) and 3.9 (trunk). I suspect the library is named libLLVM.so on Linux and BSD for llvm 3.8 and later.
I guess it depends on the distro in the case of Linux, in debian it's /usr/lib/x86_64-linux-gnu/libLLVM-3.8.0.so.1
Or maybe it has to do with the build system. llvm deprecated autoconf in favor of cmake in llvm-3.8, so maybe it's that their cmake build system is not appending the version number but the deprecated autoconf-based build system still is.
In the openSUSE changelog for WebKit I see: " + Inject a llvm-config wrapper script into ~/bin, which replaces the original's output of static libs with dynamic shared objects. This is supposedly going to be corrected with LLVM 3.8." https://build.opensuse.org/package/view_file/GNOME:Next/webkit2gtk3/webkit2gtk3.changes Jeremy, do you know if there is some less-hacky way to get shared libraries out of llvm-config in LLVM 3.8, as implied by that changelog? If so, we should switch to using that... otherwise we will just have to add whatever hacks necessary to FindLLVM.cmake to make it work. You could also build with -DENABLE_FTL_JIT=OFF to avoid the dependency on LLVM, but this doesn't look too hard to solve....
(And does anyone know why LLVM thinks it's remotely acceptable to not ship a pkg-config file?)
I'm going to remove FindLLVM.cmake due to r196729.