On Fri, 14 Feb 2025 at 08:32:47 +0200, Timo Aaltonen wrote: > Philippe SWARTVAGHER kirjoitti 14.2.2025 klo 0.27: > > So I guess we could stop shipping libspirv.a
According to https://codesearch.debian.net/search?q=-lSPIRV%5Cb&literal=0 libSPIRV.a is explicitly linked by at least retroarch and some (older?) versions of ffmpeg, plus an unknown amount of non-packaged code. So it likely can't be removed just yet. Perhaps it could be removed when testing reopens for disruptive changes at the beginning of the forky cycle? > > Lintian error: > > E: glslang-dev: no-code-sections [usr/lib/x86_64-linux-gnu/libSPIRV.a] If this library is being kept for backward-compatibility only and we already know that it's intentionally empty, then I think it would be fine to override the lintian tag. > > However, I'm not sure if we should keep the spirv.pc file According to https://codesearch.debian.net/search?q=pkg.*spirv&literal=0 it appears to be required by filament (upstream source) and shaderc (debian/tests only), plus an unknown amount of non-packaged code. At this stage in the release cycle, I think it would be helpful to keep it for trixie, and look again at removing it when testing reopens for disruptive changes at the beginning of the forky cycle. > > Regarding the failling autopkgtest (which is the problem preventing > > migration), I found two possible fixes: > > - change the line in the test glslang-dev to > > "${CXX}" -std=c++17 -o spirv spirv.cpp $("$PKG_CONFIG" --cflags --libs > > glslang SPIRV-Tools) This would defeat the purpose of that test. The purpose of that test is to confirm that, if we do something that historically worked (linking to spirv.pc and calling functions that were previously provided by libSPIRV.a), it still works. smcv
