search

getsolus / packages

Solus Package Monorepo & Issue Tracker
53 stars 68 forks source link

Build `spirv-tools` and `glslang` as shared libraries (T9051) #298

Open celticmagic opened 11 months ago

celticmagic commented 11 months ago
Alex Vorobyev (#aleksvor), 2020-06-04 07:39:40 UTC

Currently these packages contain only static libs which get "compiled-in" in all their reverse dependencies. According to CMakeLists, these packages can be build as shared libs if `BUILD_SHARED_LIBS` flag is set while invoking CMake (see [glslang script](https://github.com/KhronosGroup/glslang/blob/8db9eccc0baf30c9d22c496ab28db0fe1e4e97c5/CMakeLists.txt#L18), for spirv-tools the flag is the same). I've found revdeps of glslang which currently contain copies of glslang code instead of linking to shared lib: 1. `vulkan-tools` 2. `libplacebo` Also glslang is a dependency of MangoHud (D8365) which could make use of shared library too. Probably there are other revdeps of glslang that I didn't found. I've tried building shared `spirv-tools` and `glslang` locally and rebuilding libplacebo against them - it correctly links to shared libglslang and works as expected (Vulkan renderer in mpv works). I wonder about opinion of Core and / or Globals on this matter - is there a reason why we build these libraries as static and should we switch them to shared?
celticmagic commented 11 months ago
FvG (#Girtablulu), 2020-06-05 08:46:03 UTC

ikey build them static but couldn't find a reason why
celticmagic commented 11 months ago
Beatrice T. Meyers (#DataDrake), 2020-11-14 18:11:32 UTC

I can't see a reason not to, but we might still need the static libs for some things. So testing needed.
celticmagic commented 11 months ago
Martin Reboredo (#YakoYakoYokuYoku), 2021-01-16 15:55:20 UTC

Reasons for only building statically are mainly stability and linking issues ([example](https://github.com/KhronosGroup/glslang/issues/1484)), but mostly of them have been addressed nowadays.