Bug 180678 - [Linux][JSCOnly] Unable to build JSC fully statically.
Summary: [Linux][JSCOnly] Unable to build JSC fully statically.
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Linux
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2017-12-11 16:22 PST by Carlos Alberto Lopez Perez
Modified: 2018-05-02 11:33 PDT (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Alberto Lopez Perez 2017-12-11 16:22:43 PST
I'm trying to build a static binary of JSC for Linux (with the JSCOnly port).

$ cd WebKit && mkdir build && cd build
$ cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DPORT=JSCOnly -DENABLE_STATIC_JSC=ON .. && ninja

The resulting binary is a 20mb JSC file that doesn't link with a libjavascriptcore lib (its static in that sense)

But its still linking with several system libraries like icu, libstdc++, etc.

$ file bin/jsc
bin/jsc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=d269adab6d32f9a2e193dbe4a5b5d85378907420, not stripped

$ ls -sh bin/jsc
20M bin/jsc

$ ldd bin/jsc
	linux-vdso.so.1 (0x00007fffd5316000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f53f6dd6000)
	libicudata.so.52 => /usr/lib/x86_64-linux-gnu/libicudata.so.52 (0x00007f53f5569000)
	libicuuc.so.52 => /usr/lib/x86_64-linux-gnu/libicuuc.so.52 (0x00007f53f51eb000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f53f4fce000)
	libicui18n.so.52 => /usr/lib/x86_64-linux-gnu/libicui18n.so.52 (0x00007f53f4bbc000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f53f48b1000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f53f45b0000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f53f439a000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f53f3fef000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f53f6fda000)

So its not really portable between different Linux distributions that may have a different major versions of this libraries.

For example, try to run this JSC binary that I built like that on Debian Jessie (current oldstable) with clang-3.8 on Fedora 25 and it won't work:

$ wget https://people.igalia.com/clopez/wkbug/static_jsc/jsc
$ chmod +x jsc
$ ./jsc 
./jsc: error while loading shared libraries: libicudata.so.52: cannot open shared object file: No such file or directory
Comment 1 Konstantin Tokarev 2017-12-12 00:04:04 PST
Static linking of ICU is somewhat out of scope of WebKit's build system. CMake's find modules will always prefer shared libraries to static if they are found, so to get fully static build you need to force it into using your custom build of ICU via -DCMAKE_PREFIX_PATH (pointing to prefix with static ICU)

To get gcc runtime libraries and libc statically linked you should add -static to compiler flags, i.e. -DCMAKE_C_FLAGS=-static -DCMAKE_CXX_FLAGS=-static

Note that glibc is not really friendly to static linking (e.g. name resolving may be broken unless you find a way to link nss plugins), so you may want to use "-static-libgcc -static-libstdc++" instead of "-static", in this case your binary will work on all Linux systems with same or newer glibc than what you used to build (building on old distro like centos 6 should be enough to cover most users)

Other approach is static linking with alternative libc like uclibc or musl.
Comment 2 Konstantin Tokarev 2017-12-12 00:13:38 PST
Though you can just use this dynamically linked build, just make sure you are building on old distro, and bundle all dependency *.so's with tool like linuxdeployqt (or even manually)
Comment 3 Konstantin Tokarev 2017-12-12 00:18:02 PST
Note that linxdeployqt automatically uses $ORIGIN in RUNPATH, while if you are bundling manually you need to use patchelf or use launcher script with LD_LIBRARY_PATH
Comment 4 Konstantin Tokarev 2017-12-12 00:21:21 PST
So, you need to choose between complex build setup and getting single portable executable, or simple setup and using bundled libraries
Comment 5 Carlos Alberto Lopez Perez 2018-05-02 11:33:26 PDT
Closing this.

Although I'm still unable to build a jsc static binary, this is not longer a need for me.
On bug 184699 I took an alternative approach of generating a "jsc bundle".

Feel free to reopen if someone is still interested on this.