Underlinking to SDL2

[khumba]

Hi @jorio,

TL;DR: Would you consider adding an explicit dependency on SDL2's library to Pomme's CMakeLists.txt?

target_link_libraries(${PROJECT_NAME} SDL2)

I'm not sure how interested you are in downstream packaging issues, but there is a correctness issue with libPomme.so underlinking to libSDL2.so -- it depends on symbols from libSDL2.so but doesn't declare a NEEDED dependency on it, because the above CMake command is missing. I understand that Pomme is bundled in your games' builds which do link correctly, so this doesn't matter in practice for you. But it comes up when packaging for distros, where bundled libraries are split out into their own packages (which I've done) and automated QA will check for shared libraries not declaring dependencies properly.

I've patched this in my (unofficial) Debian builds and and have a ticket for myself to fix my (also unofficial) Gentoo builds[1], but I thought first I would check if you'd be willing to add the necessary line upstream.

Thanks!

[1] https://todo.sr.ht/~khumba/khoverlay/21

[jorio]

Hi @khumba! Unfortunately this line breaks the Mac and Windows builds of the games (carried out through CI script build.py in each game).

My binary distributions of the games all link Pomme as a static lib, because I originally made it evolve with each new port without much concern for backwards compatibility with older ports. To be safe, I’d recommend linking Pomme statically for this reason, although that’s more or less moot today (all games have been updated to a recent-ish commit of Pomme and I don’t have new ports in the works for now).

That said, if you want to distribute Pomme as a shared library, perhaps we could gate the target_link_libraries statement with a special flag so that the Mac/Windows build process doesn’t need to change.

[jorio]

An update on this: I'm updating the Pangea games to SDL3, and in the process I've implemented your suggestion (ced44f2 on branch 'sdl3-wip').

I'm waiting for Flatpak runtimes to start shipping SDL3 before I cut new releases for the games. In the meantime, the first game that is SDL3 ready is Mighty Mike. Let me know if this works for your purposes.

[khumba]

Hi, thanks for the prompt response and sorry for disappearing after filing this.

Hi @khumba! Unfortunately this line breaks the Mac and Windows builds of the games (carried out through CI script `build.py` in each game).

Ah, see I know nothing about linking on platforms other than Linux. It figures that there are important differences, and apologies for the incomplete suggestion.

My binary distributions of the games all link Pomme as a static lib, because I originally made it evolve with each new port without much concern for backwards compatibility with older ports. To be safe, I’d recommend linking Pomme statically for this reason, although that’s more or less moot today (all games have been updated to a recent-ish commit of Pomme and I don’t have new ports in the works for now).

I did start out by bundling Pomme with each game, but early last year I figured that most of the games are caught up to either the same or equivalent Pomme versions now, enough to make unbundling worth it. Doubly so on Gentoo where the user had to wait for Pomme to compile multiple times (yes, it's a quick build, but still).

That said, if you want to distribute Pomme as a shared library, perhaps we could gate the `target_link_libraries` statement with a special flag so that the Mac/Windows build process doesn’t need to change. An update on this: I'm updating the Pangea games to SDL3, and in the process I've implemented your suggestion (ced44f2 on branch 'sdl3-wip'). I'm waiting for Flatpak runtimes to start shipping SDL3 before I cut new releases for the games. In the meantime, the first game that is SDL3 ready is [Mighty Mike](https://github.com/jorio/MightyMike/). Let me know if this works for your purposes.

Awesome, thank you very much! I will put together a new package with that patch dropped and report back.