[Webkit-unassigned] [Bug 247985] New: [GTK][WPE] Fix relocation issues running the MiniBrowser or the layout tests when the path on disk changes

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 16 10:26:54 PST 2022


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

            Bug ID: 247985
           Summary: [GTK][WPE] Fix relocation issues running the
                    MiniBrowser or the layout tests when the path on disk
                    changes
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WPE WebKit
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: clopez at igalia.com
                CC: bugs-noreply at webkitgtk.org

When WebKit is built the path of the repository (where you have the checkout) is stored in the binaries in different ways:

 - The path to the WebKit libraries is stored as an rpath on the ELF binaries
 - The CMake system also defines some constant strings to the build like WEBKIT_EXEC_PATH and WEBKIT_INJECTED_BUNDLE_PATH that end going into the binaries as default values.
   This default values can be overriden at run-time via environment variables, but the current tooling is not doing that.

This means that if you build WebKit in a directory and then move the directory to a different path (without rebuilding) you are going to find errors and crashes:

Example of error:
                 Release/bin/MiniBrowser: error while loading shared libraries: libwebkit2gtk-4.0.so.37: cannot open shared object file: No such file or directory


This is not an issue with the flatpak build, because the flatpak build maps the buildirectory to /app so the path doesn't change in that case even if you move the directory.

But it is an issue for builds not using flatpak. Specifically I found this on a bots that I'm working on where the builder builds on a different path than the tester (and the tester downloads the build product from the builder, doesn't build it)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221116/a9f6349f/attachment.htm>


More information about the webkit-unassigned mailing list