Mesa: Link SPIRV-Tools statically and update Mesa from 26.2.1 to 26.2.2 #3440
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CMakeLists.txt:380 hardcodes the pkg-config libraries as
Libs: -L${libdir} -lSPIRV-Tools-opt -lSPIRV-Tools -lSPIRV-Tools-link
which is upside down. libSPIRV-Tools-link needs symbols from
libSPIRV-Tools-opt and from the core library, as its NEEDED entries show
in the shared build:
$ objdump -p /usr/lib/libSPIRV-Tools-link.so | grep NEEDED
NEEDED libSPIRV-Tools-opt.so
NEEDED libSPIRV-Tools.so
For shared libraries the order is irrelevant, but ld searches an archive
only at the place where it is named, so a static build leaves every
symbol that -link alone pulls in undefined. Name the archives the other
way round.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
SPIRV-Tools sets SOVERSION on none of its libraries, and with
BUILD_SHARED_LIBS=ON the plain libSPIRV-Tools.so target is the
full-visibility one, which exports the whole C++ interface that upstream
explicitly gives no stability guarantee for (CMakeLists.txt:163):
$ objdump -p /usr/lib/libSPIRV-Tools.so | grep SONAME
SONAME libSPIRV-Tools.so
$ grep -rn SOVERSION SPIRV-Tools-vulkan-sdk-1.4.350.1/
$
Every update therefore rebinds the consumers to a different C++ ABI, and
without a soname nothing gates it: the mismatch surfaces as an undefined
symbol at load time, or silently not at all.
Build the C++ libraries static instead and leave only
libSPIRV-Tools-shared.so, the C API with hidden visibility, shared. That
is upstream's default and intended configuration
(SPIRV_TOOLS_BUILD_STATIC defaults to ON, BUILD_SHARED_LIBS to OFF), and
it removes the mismatch by removing the object that can mismatch. The
cost is small: code and rodata of the three libraries the consumers use
come to 3.6 MB together, the rest of the 183 MB libSPIRV-Tools-opt.so is
debug info.
CMake does not imply position independent code for static targets, so ask
for it explicitly: both consumers link the archives into shared objects.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
glslang is built with ALLOW_EXTERNAL_SPIRV_TOOLS=ON and binds the
unversioned C++ libraries of spirv-tools:
$ objdump -p /usr/lib/libglslang.so | grep NEEDED
NEEDED libSPIRV-Tools-opt.so
NEEDED libSPIRV-Tools.so
spirv-tools 1.4.357.0-1 ships those as archives, so pick up the new
revision. The libraries are found through the CMake config packages,
which carry the dependencies between them, so no configure change is
needed here.
Increment revision to 1.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
pmenzel
force-pushed
the
spirv-tools-static-cxx-abi
branch
from
f02a4c9 to
9da30e6
Compare
Mesa 26.2.2 is a bug fix release on the 26.2 branch, released on
2026-09-02. Among the fixes are Navi 10 NGG culling GPU hangs, radeonsi no
longer loading for GCN1 / Pitcairn with the radeon driver, RADV ignoring an
indirect draw count of zero and the armhf build failure.
Building the package is also going to fix the issue below:
$ eglinfo
EGL client extensions string:
EGL_EXT_client_extensions, EGL_EXT_device_base, EGL_EXT_explicit_device,
EGL_EXT_platform_base, EGL_EXT_platform_device, EGL_EXT_platform_wayland,
EGL_EXT_platform_x11, EGL_EXT_platform_xcb,
EGL_KHR_client_get_all_proc_addresses, EGL_KHR_debug,
EGL_KHR_platform_gbm, EGL_KHR_platform_wayland, EGL_KHR_platform_x11,
EGL_MESA_platform_gbm, EGL_MESA_platform_surfaceless
MESA-LOADER: failed to open dri: libSPIRV-Tools.so: cannot open shared object file: No such file or directory (search paths /usr/lib/gbm, suffix _gbm)
GBM platform:
eglinfo: eglInitialize failed
Wayland platform:
eglinfo: eglInitialize failed
`libSPIRV-Tools.so` has no SOVERSION, and it exports the unstable C++ API.
Upstream’s guidance is to link the C++ interface statically and keep
`SPIRV-Tools-shared.so` for the C API. As it stands, any spirv-tools bump
silently rebinds Mesa to a different C++ ABI with no version gate — exactly
the class of breakage that happened, when the package *spirv-tools* was not
correctly upgraded.
Nine objects of the package bind the unversioned C++ libraries of
spirv-tools, the Vulkan drivers and the VA-API drivers the core library,
rusticl additionally the optimizer and the linker:
$ objdump -p /usr/lib/libRusticlOpenCL.so.1 | grep NEEDED
NEEDED libSPIRV-Tools-opt.so
NEEDED libSPIRV-Tools.so
NEEDED libSPIRV-Tools-link.so
Mesa needs the C++ interface – `src/compiler/clc/meson.build:86` probes for
spvtools::LinkerOptions::SetAllowPtrTypeMismatch – and cannot be pointed at
libSPIRV-Tools-shared.so, which exports the C API only. With spirv-tools
1.4.357.0-1 it links the archives that dependency('SPIRV-Tools') now
resolves to.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
pmenzel
force-pushed
the
spirv-tools-static-cxx-abi
branch
from
9da30e6 to
75adf77
Compare
Sign in
to join this conversation on GitHub.
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update with
sudo bee update spirv-tools-1.4.357.0-1 glslang-16.5.0-1 mesalib-26.2.2-0.Static linking fixes the issue below, where package spirv-tools was not updated correctly: