SDL2 in Sniper cannot be used for shared objects #736
Comments
Signed-off-by: Michael Pollind <[email protected]> ValveSoftware/steam-runtime#736
https://gitlab.steamos.cloud/steamrt/sniper/sdk/-/blob/steamrt/sniper/README.md https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md - Revert to clang-11 - Don't install system libs that won't be provided to users in the SLR - Use system libs where possible - Update Dockerfile to match CI pipeline - [temp] Manually find Ogg/Vorbis when using system libs - revert once resolved: ValveSoftware/steam-runtime#735 - fix rpath for build - issue using sdl from steam-runtime: ValveSoftware/steam-runtime#736 - set fpic for all targets - Don't use system ogg/vorbis ValveSoftware/steam-runtime#735 Signed-off-by: Michael Pollind <[email protected]> Co-authored-by: Gelmo <[email protected]>
https://gitlab.steamos.cloud/steamrt/sniper/sdk/-/blob/steamrt/sniper/README.md https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/slr-for-game-developers.md - Revert to clang-11 - Don't install system libs that won't be provided to users in the SLR - Use system libs where possible - Update Dockerfile to match CI pipeline - [temp] Manually find Ogg/Vorbis when using system libs - revert once resolved: ValveSoftware/steam-runtime#735 - fix rpath for build - issue using sdl from steam-runtime: ValveSoftware/steam-runtime#736 - set fpic for all targets - Don't use system ogg/vorbis ValveSoftware/steam-runtime#735 Signed-off-by: Michael Pollind <[email protected]> Co-authored-by: Gelmo <[email protected]>
|
I don't think we normally recommend linking to SDL statically: SDL frequently gets updated with e.g. support for newer game controllers, and it's harder to make that take effect if an arbitrary version of SDL has been statically linked into a game. Linking to SDL statically also doesn't actually link fully statically, because some of SDL's dependencies (notably I had thought that the toolchains in Debian 11 (and therefore sniper) normally create position-independent executables, which isn't possible if static libraries aren't PIC, but it seems that isn't the case. |
I'm confused by this; do you mean "to be able to link [to SDL] dynamically", rather than "... statically"? Or do you mean you tried to link your main executable as purely static? (That's generally impossible for games, because user-space graphics drivers like Vulkan and (E)GL rely on being able to load GPU-specific drivers dynamically.)
For a game that runs in the sniper container runtime as provided by Steam, it is never necessary to provide your own SDL2: if you dynamically link to SDL2, sniper guarantees to provide a relatively up-to-date version of SDL2 (it's rarely more than a couple of months behind upstream). For example the copy of Endless Sky distributed via Steam relies on this. If you're using the sniper SDK as a convenient "old-ish" environment to build binaries that will be run somewhere else (outside Steam), I'd still recommend linking SDL2 dynamically, and either bundling a suitable SDL shared library (which your users can easily remove to use their system copy if they know that the system copy is newer/better) or documenting a minimum required system version of SDL2. If you link your executable or dependent library with something like |
|
soo, i guess it's unable to link the shared sdl2 library that is bundled with the sniper docker container. |
I don't understand this, please could you elaborate? You can link a game or library to the SDL2 shared/dynamic library provided by the sniper SDK. That's what we would recommend. Endless Sky and Team Fortress 2 are examples of games that do this successfully. But the compiler error messages in your initial report indicate that you are linking your own shared/dynamic library to the SDL2 static library provided by the sniper SDK. That won't work. Is that what you meant to do? I think it would help if you describe:
|
Your system information
registry.gitlab.steamos.cloud/steamrt/sniper/sdk:latestPlease describe your issue in as much detail as possible:
Looks like SDL2 provided in the Sniper image was not built with Position-Independent Code (PIC), and is therefore unable to be used to build shared objects:
Is Valve able to provide SDL2 built with
-fPIC? We would need to significantly restructure things to be able to link statically, so in the meantime we are building and providing SDL2 with our game for Linux users.The text was updated successfully, but these errors were encountered: