Bug 151559 – [CMake] Do not use LLVM static libraries for FTL JIT

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Guilaume Ayoub]

When I'm trying to compile WebkitGTK 2.11.2, I get:

> No rule to make target '/usr/lib64/libLLVMSupport.a', needed by 'DerivedSources/JavaScriptCore/WebKitLLVMLibraryToken.h'.

I can build WebkitGTK 2.11.1 successfully with the same configuration flags.

[Michael Catanzaro]

It's because we turned on FTL JIT. You need to either install LLVM on your system, including LLVM static libraries (the llvm-static package on Fedora), or run cmake with -DENABLE_FTL_JIT=OFF.

But this is also a bug in our CMake build system. You should have gotten a nice error message when running CMake. Currently our build system is smart enough to check that you have LLVM itself installed, but we additionally depend on those static libraries, and while we check for those separately, we don't error out properly if they're missing.

[Michael Catanzaro]

Also, we need to determine if there is a good reason for depending on LLVM static libs. Gentoo does not ship these at all. We ship them in Fedora, but in a separate llvm-static package. We're only allowed to link Fedora packages to static libraries in "exceptional circumstances," and to my knowledge we do not have one here.

Hey Filip, do you know why we are linking with LLVM static libs instead of a proper shared library?

[Csaba Osztrogonác]

(In reply to comment #2)
> Also, we need to determine if there is a good reason for depending on LLVM
> static libs. Gentoo does not ship these at all. We ship them in Fedora, but
> in a separate llvm-static package. We're only allowed to link Fedora
> packages to static libraries in "exceptional circumstances," and to my
> knowledge we do not have one here.
> 
> Hey Filip, do you know why we are linking with LLVM static libs instead of a
> proper shared library?

https://trac.webkit.org/changeset/157260 answers the question why.

( https://bugs.webkit.org/show_bug.cgi?id=142128#c18 )

[Michael Catanzaro]

That explains why we need to load a shared library with dlopen (libllvmForJSC.so) instead of linking to LLVM normally. That's unconventional but fine. Now, libllvmForJSC.so is linked statically to LLVM, which is not generally permitted in Fedora. I want to know why we don't dynamically link libllvmForJSC.so to the system LLVM. Surely we can override cxa_atexit regardless, so I don't think we need to link statically.

[Michael Catanzaro]

OK, my vote is to either fix this or disable FTL again before 2.12. Using static libs is not considered acceptable on Linux, and it's causing build problems for openSUSE and Gentoo, which don't have LLVM static libs at all; no doubt it will be problematic for other distros too.

openSUSE came up with a rather innovative solution [1] to use -DLLVM_CONFIG_EXE at cmake time to pointing cmake to a script that wraps llvm-config like so:

#!/bin/bash

/usr/bin/llvm-config $1 |sed "s,\\.a,\\.so,g"

Yuck, but their package is reportedly working without issues, so I doubt the static libs were ever really needed. It would be better to use a similar wrapper around llvm-config to handle this automagically than to continue using static libs.

[1] https://build.opensuse.org/package/rdiff/GNOME:Next/webkit2gtk3?opackage=webkit2gtk3&oproject=GNOME:Factory&rev=87

[Carlos Garcia Campos]

(In reply to comment #5)
> OK, my vote is to either fix this or disable FTL again before 2.12. Using
> static libs is not considered acceptable on Linux, and it's causing build
> problems for openSUSE and Gentoo, which don't have LLVM static libs at all;
> no doubt it will be problematic for other distros too.
> 
> openSUSE came up with a rather innovative solution [1] to use
> -DLLVM_CONFIG_EXE at cmake time to pointing cmake to a script that wraps
> llvm-config like so:
> 
> #!/bin/bash
> 
> /usr/bin/llvm-config $1 |sed "s,\\.a,\\.so,g"
> 
> Yuck, but their package is reportedly working without issues, so I doubt the
> static libs were ever really needed. It would be better to use a similar
> wrapper around llvm-config to handle this automagically than to continue
> using static libs.

It's not that easy, this hack works for SUSE because they are building llvm with CMake, so they have a .so for each static library. However, if llvm is built using autotools (like debian and fedora do) what we have is a single .so file. So we need to detect this as well at configure.

[Carlos Garcia Campos]

Created attachment 268863 [details]
Patch

I've tested this in debian, having both the global .so and the individual .a files installed, and it uses the global .so. It would be great if someone could test this in other distros, fedora, gentoo and suse at least. It first checks if there's a global .so, and if it isn't it uses the libs information from llvm-config instead of the lib files, so that in case of having both the .so and .a files for the individual libs, it will still prefer the .so ones, and if only .a files are installed, it will use those.

[Michael Catanzaro]

Comment on attachment 268863 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=268863&action=review

Thanks for working on this. I will test in on my Fedora box and on openSUSE OBS.

> Source/cmake/FindLLVM.cmake:33
> +# We need to build the soname manually in any case, since there's no way to get it from llvm-config.

There's currently no way to get it from llvm-config. I've heard this might be possible with LLVM 3.8.

[Michael Catanzaro]

It builds and runs fine on Fedora. It also builds fine on openSUSE.

[Carlos Garcia Campos]

Committed r195009: <http://trac.webkit.org/changeset/195009>

[Jeremy Huddleston Sequoia]

This doesn't work on Windows or OSX, and it doesn't work for current development versions of llvm (on any platform).

Followup in bug #153191.