[webkit-dev] Thought about Nix JavaScriptCore port

[Michael Catanzaro]

Hi,

On Sun, 2016-01-31 at 15:22 -0800, Eric Wing wrote:
> - libICU is a difficult dependency because it is big and it is not
> guaranteed to be on all systems. (Some context, I’m interested in
> deploying binaries, e.g. SteamOS, Android, so I can’t make users
> install it via package management). So static linking is the
> preferred
> method. (It’s discussed in the above doc.) Currently, JavaScriptCore
> needs to additionally link against libicudata because the other
> libraries have a dependency on it. Static linking doesn’t pick up on
> the implicit dependency. I don’t think it hurts anything in the
> dynamic library case.

I don't mind if static linking is an option. (We will keep using
dynamic linking for WebKitGTK+, though, as it's what all our
distributors require.)

> - soname versioning *must* be disabled for Android. I would also like
> an option to shut it off for regular desktop Linux. I am bundling
> JavaScriptCore with my app, so the versioning is mostly a nuisance
> for
> my build system.

Ditto for soname versioning.

> - Can somebody explain libllvmForJSC.so? libJavaScriptCore does not
> link to it. Is it actually used? Is it a dlopen type thing? If so,
> since I’m bundling JSCore with my app, what are the rules for where
> to
> place libllvmForJSC so it can be found/loaded? Is there an C API to
> set the path?

Yes, it's a dlopen-type thing. But it's about to go away because we're
about to remove the LLVM dependency (see the recent topics on B3).

See: https://bugs.webkit.org/show_bug.cgi?id=153478

> - I think libedit was required for libllvmForJSC.so. libedit is not
> included with SteamOS. I built my own static version and had to set
> my
> $LIBRARY_PATH environment to make sure it got picked up. This seems
> like it should have gone through the CMake FInd_Library() mechanism
> so
> I could specify the location directly to the build system.

Yes, this is an annoying bug. If it's only needed for libllvmForJSC,
then hopefully the problem is about to go away. :)

> - Some general feedback on the gcc 4.9.0 requirement to the WebKit
> team as a whole. This is really hard for SteamOS because it only has
> 4.8.1 (and I don't think I can upgrade without introducing new
> dependencies on glibc/libstdc++ that nobody would have on their
> machines.) I consider myself fortunate that things built under its
> provided clang 3.6.

Maybe we should lower this requirement.

If you remove the version checks and build with
-DENABLE_DATABASE_PROCESS=OFF -DENABLE_INDEXED_DATABASE=OFF it will
work. See for an example:

https://build.opensuse.org/package/show/GNOME:Next/webkit2gtk3

Actually, it's possible that database process would work with newer
versions of GCC 4.8, but we haven't tested. 4.8.1 is almost certainly
broken, though.

If you're just building JSC, you can safely remove the version checks
(for now).

Michael