SDL2::SDL2main cmake target undefined in Sniper
Using CMake on the latest sniper runtime (19/09/22), CMake can't find the SDL2::SDL2main target anymore. The library libSDL2main.a is present in /usr/lib, but CMake is unable to find it (as seen by the missing target).
The runtime from early August (or it might have been late July) doesn't have this problem. I suspect that this has to do with the update to SDL 2.24.0 in the September build. I'm not sure exactly what causes this though.
Any ideas? Thanks
@quyykk, can you provide repro steps?
@madebr, do you have any ideas?
The viper sdk does not carry this patch: https://github.com/libsdl-org/SDL/commit/62302d08f13ca5303135505c6b355afbbf069745 (which is queued for 2.24.x)
madebr seems to have identified the issue already. But just for reference, here's the CMakeLists.txt file that I used:
cmake_minimum_required(VERSION 3.13)
project(Test LANGUAGES CXX)
find_package(SDL2 CONFIG REQUIRED)
add_executable(program test.cpp)
target_link_libraries(program PRIVATE SDL2::SDL2 SDL2::SDL2main)
and a sample test.cpp file:
#include <iostream>
#include <SDL2/SDL.h>
int main()
{
if(SDL_Init(SDL_INIT_VIDEO) != 0)
return -1;
std::cout << "initialized!\n";
return 0;
}
@quyykk, may I use those files under SDL's license? I'd like to add a test based on that one to the Debian packaging (which the Steam Runtime packaging is based on) to make sure this doesn't regress.
Workaround: link with SDL2::SDL2 on all platforms, and only add SDL2::SDL2main on non-Linux platforms (libSDL2main.a is empty on Linux anyway).
may I use those files under SDL's license?
Sure thing. Oh I didn't know that libSDL2main.a is empty on Linux anyways; thanks for the workaround!
https://github.com/libsdl-org/SDL/issues/6119 upstream.
This is also going to affect soldier, and likely also the next scout SDK update (we backported SDL 2.24 to soldier already, and there's a scout update queued up for a future Steam beta).
Probably a better workaround is to do "option 3" from https://github.com/libsdl-org/SDL/issues/6119#issuecomment-1225012261 in your game's build system. You won't need to remove that workaround after SDL is fixed, it should be OK to keep it forever.
Another thing you can do if there is a compile-time regression in the SDK (as opposed to a runtime bug) is to "pin" your game's build system to a specific SDK version: it's generally OK to build with a SDK from the same branch that is older than the current runtime, as long as you don't try to use a SDK that is newer than the runtime your users will have. As documented in https://gitlab.steamos.cloud/steamrt/sniper/sdk, any of the versions visible in https://repo.steampowered.com/steamrt-images-sniper/snapshots/ has a corresponding SDK tag which you can fetch with:
podman pull registry.gitlab.steamos.cloud/steamrt/sniper/sdk:0.20220803.0
The SDK tags correspond to the "sniper Platform/SDK" mentioned in https://gitlab.steamos.cloud/steamrt/steamrt/-/wikis/Sniper-release-notes. 0.20220803.0 was the last one before we upgraded to SDL 2.24.
If anyone runs into this same problem for soldier or scout, all the SDKs work very similarly, so you can do the same workarounds with those.
This is fixed in SDL 2.24.1, which will be included in the next beta of sniper and soldier, and a future beta of scout.
Today's soldier and sniper beta SDK updates registry.gitlab.steamos.cloud/steamrt/soldier/sdk:0.20221017.1 and registry.gitlab.steamos.cloud/steamrt/sniper/sdk:0.20221017.1 (also available as ...:beta) should resolve this. Both branches identify themselves as BUILD_ID="0.20221017.1" in /etc/os-release.
Please note that games built with the beta SDK are not guaranteed to work correctly with the stable container runtime. Developers can opt-in to the client_beta container runtime branch to get a runtime that matches the beta SDK, but the version shipped on Steam should be built against registry.gitlab.steamos.cloud/steamrt/sniper/sdk:latest or an earlier version like registry.gitlab.steamos.cloud/steamrt/sniper/sdk:0.20220803.0, and tested with the default branch of the container runtime.
The 0.20221017.1 versions will be promoted to stable status when they have had some more testing. We'll update this issue when that has happened.
The next update to the scout SDK might have the same bug, depending what order things get released in (0.20220928.1 has SDL 2.24.0 and this issue, but has not had a public release, and might get superseded by an updated version with 2.24.1 before that happens). If an affected version of scout does get released, the workaround is to either hold back your scout SDK to 0.20220802.0 until a fixed version is available, or link SDL2::SDL2main conditionally (option 3 in https://github.com/libsdl-org/SDL/issues/6119#issuecomment-1225012261).
The scout beta release 0.20220928.1 is now public, and unfortunately it does have this issue. It will be fixed in a future beta update.
The scout beta release 0.20220928.1 is now public, and unfortunately it does have this issue. It will be fixed in a future beta update.
That release has now been superseded by scout beta release 0.20221019.0, which fixes this issue.
Closing per the last comment.
The 0.20221017.1 versions will be promoted to stable status when they have had some more testing. We'll update this issue when that has happened.
This has now happened, so SDL2::SDL2main should be available in registry.gitlab.steamos.cloud/steamrt/soldier/sdk:latest and registry.gitlab.steamos.cloud/steamrt/sniper/sdk:latest again.
scout beta release 0.20221019.0, which fixes this issue
This was promoted to stable status on or before 2022-11-17, so SDL2::SDL2main should also be available in registry.gitlab.steamos.cloud/steamrt/scout/sdk:latest.