Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: c5cd363ad5f2b7b0ca310fa9705d318e3d879f77
https://github.com/WebKit/WebKit/commit/c5cd363ad5f2b7b0ca310fa9705d318e3d879f77
Author: Elliott Williams <[email protected]>
Date: 2026-01-06 (Tue, 06 Jan 2026)
Changed paths:
M Source/WebKit/Configurations/BaseXPCService.xcconfig
Log Message:
-----------
[Back-deployment] Crash in STP: "Library not loaded:
@rpath/libswiftCompatibilitySpan.dylib"
https://bugs.webkit.org/show_bug.cgi?id=304649
rdar://166804178
Reviewed by Richard Robinson and Alexey Proskuryakov.
In relocatable builds, we rely on the DYLD_LIBRARY_PATH baked into
WebKit's XPC services to load dylibs. In STP, this load command is set
up so that the install paths for ANGLE
(@loader_path/../../../libANGLE-shared.dylib)
and webrtc (@loader_path/../../../libwebrtc.dylib) can be resolved.
The Swift runtime compatibility libraries that our build copies from the
toolchain are linked against with an rpath-based install path
(@rpath/libswiftCompatibilitySpan.dylib). So, the DYLD_LIBRARY_PATH we
have doesn't work. It needs to be combined with the relative path
from the service bundle to the shallow bundle (../../..).
Adding new search paths to DYLD_LIBRARY_PATH is risky, since we would
need to carefully consider every path WebKit.framework can be installed
at, to ensure it is never possible to load untrusted code from outside
the bundle. Instead, add `@loader_path/../../../` to the XPC service's
rpath list, so that rpath resolution uses the same semantics as our own
two dylibs.
* Source/WebKit/Configurations/BaseXPCService.xcconfig:
Canonical link: https://commits.webkit.org/305178@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
