[Webkit-unassigned] [Bug 99344] New: WebKit should be prepared for conflicting versions of shipped libraries

[bugzilla-daemon at webkit.org]

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

           Summary: WebKit should be prepared for conflicting versions of
                    shipped libraries
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Windows 7
            Status: UNCONFIRMED
          Severity: Blocker
          Priority: P2
         Component: Platform
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: grant_gayed at ca.ibm.com


As an embeddable component, WebKit should be robust to conflicts between its shipped libraries and similar libraries from other sources.  The Eclipse SWT Browser has encountered two cases of its WebKit embedding failing due to conflicts between shipped libraries:

- Oracle's latest Java runtimes now ship libxml.dll, and it's a different version than the libxml.dll that's shipped with WebKit.  As a result, the Browser's attempt to embed WebKit now fails on Windows because the libxml.dll from the Java runtime is loaded instead of the libxml.dll from WebKit when resolving the dependencies of WebKit.dll (Windows' .dll search order favors libraries in the application directory).

- SWT's Browser can also embed Gecko.  However attempts to create WebKit- and Gecko-based Browser instances in the same process fail due to a conflict between their shipped SQLite3 libraries (also happens on non-Windows platforms).

These cannot be worked around properly, as they both boil down to identically-named libraries with different content being loaded.  However there are changes that components like WebKit could make in order to be prepared for such cases:

1. Rename shipped libraries from their common names (eg.- libxml2.dll --> webkit-libxml2.dll).  Q: legally ok?

2. Statically link more in order to eliminate the need for separately-resolvable libraries.

3. (Windows) Bundling the dependent libraries as private assemblies rather than plain-old dll's should ensure that the expected version of a library is indeed the one that is loaded and referenced.  Also, with assemblies I believe that multiple versions of a library can co-exist in a process because the dependencies are stated in terms of the assembly name/version rather than library name.

Report is marked as a blocker because the Eclipse SWT Browser's embedding of WebKit on Windows is broken with the latest Oracle JRE, which is becoming the typical installed Java runtime version.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.