[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#980370: spirv-tools: shared library should be packaged like a shared library

On Thu, 11 Feb 2021 at 14:33:37 +0200, Timo Aaltonen wrote:
> Uh, the shared lib was supposed to be disabled in 2020.3-1, but looks like
> the build option broke since. But 2020.6 now has this merged:
> https://github.com/KhronosGroup/SPIRV-Tools/pull/3910
> which should allow building a proper shared lib, but still without
> versioning. I wonder what to do for bullseye, maybe force static like it's
> supposed to be and be happy for now?

I think the first thing to do is to disable (or just not install!) the
shared library. That doesn't need a trip through NEW and should be
straightforward; it would be good if that change can be included in

seems to indicate that nothing depends on SPIRV-Tools-shared yet.
All the search hits are in packages that bundle a copy of SPIRV-Tools,
except for vkd3d which only links to the shared library if you enable an
option that Debian apparently doesn't, and mojoshader, which is more

mojoshader doesn't *seem* to have a runtime dependency on
libSPIRV-Tools-shared, but it checks for the -shared pkg-config data,
so it might accidentally FTBFS after disabling the shared library -
but it has a popcon score of 3 and nothing depends on it, so I don't
think you should necessarily feel guilty about breaking it?

The long-term solution is to teach upstream how SONAMEs work (I already
tried on <https://github.com/KhronosGroup/SPIRV-Tools/issues/3214>,
but it seems to be a slow process); and then when that has happened,
package the library according to Policy (libspirv-tools-dev and
libspirv-tools0, or similar) and go through NEW.


Reply to: