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.
> As an embeddable component Which port of WebKit is this bug about? Not all Windows ports are embeddable. > Report is marked as a blocker We reserve this severity to bugs that block WebKit development.
The first case (conflict with latest Oracle JREs) happens with Apple's Windows port. The second case (conflict with XULRunner) happens with Apple's Windows port and the WebKitGTK port.