[Webkit-unassigned] [Bug 156823] New: ICU static linking patch and SOVERSION option to help building distributable binaries for Linux & Android

[bugzilla-daemon at webkit.org]

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

            Bug ID: 156823
           Summary: ICU static linking patch and SOVERSION option to help
                    building distributable binaries for Linux & Android
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ewmailing at gmail.com

Hi, this is my first formal patch submission. I probably could use help.
This was discussed in the mailing list thread: [webkit-dev] Thought about Nix JavaScriptCore port

The intent of these patches are to allow building JavaScriptCore for binary distribution on both GNU/Linux and Android.

This first patch adds a configurable option to enable/disable SOVERSION. Using SOVERSION generally breaks Android because its Java LoadLibrary can't handle symlinks and the SOVERSION conventions.

https://github.com/ewmailing/webkit/commit/ea68782c98cce97c56b44a86008c1a34bc323f6b


This next set is to allow building against ICU when it is a static library. ICU is problematic because it is not guaranteed to be shipped as a component and the version that is in use is not guaranteed either. For example, on Steam Linus/SteamOS, ICU is not a standard/public component. Since Steam is designed around shipping binaries to arbitrary Linux machines, there is a dependency hell problem, so being able to statically link ICU is useful. Additionally, end users may need ICU in their own products, so shipping an ICU as a dynamic library is problematic with JSCore because it could potentially conflict with the version the user needs to use for other parts of their project.

Android is the same problem but much more dire. ICU is not a public component. However, device manufacturers are allowed to use it internally. If this happens (happened to me on a Nexus 7 running 5.0.2), LoadLibrary will quietly fail to load your own copy of ICU because the OS already has one loaded. If the manufacturer is using a different version, your symbols will fail to resolve if you are lucky. If you are unlucky, you will get totally broken behavior and won't understand why. Static linking avoids this problem.

The approach to this patch is simple and doesn't add any switches to control static vs. dynamic linking. Instead, it just assumes the builder has specified only static libraries in the (CMake) build process and that is its only choice. The fix though is that with static libraries, you must link all dependencies explicitly and previously, the ICU Data library was an implicit dependency. So the build process now needs to explicitly find the ICU Data library and link to it.

This should have no significant impact for the dynamic linking case. The library is always a dependency regardless. Even when built as a data archive, ICU creates a stub library for ICU data you are still expected to link with.


(Initial patch)
https://github.com/ewmailing/webkit/commit/a6493be74f38b129b7019be9a6c01e9419f7cf74
(Fixed indentation)
https://github.com/ewmailing/webkit/commit/e2c94e8b126143402b4e17cc514c4df412de5ace


I probably need help to commit this in. I only build JSCore, and not all of WebKit. (The build process and dependency chain is a real problem/challenge for me, so I don't think I can get through the standard automated process by myself.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160421/b58f72fb/attachment-0001.html>