Support for libSDL2

[nfeske]

The libSDL2 and friends (like Mesa) are readily available at genode-world. However, to use the library from a Goa project, using CMake in particular, a few pieces are missing in Goa. Fortunately, @ssumpf happens to have those puzzle pieces in a branch https://github.com/ssumpf/goa/commits/doom3.

@ssumpf I would very much appreciate you upstreaming the libSDL2 support! Maybe even along with a simple example of using it with CMake? I'm asking because the latest version of Hatari relies on SDL2 and uses CMake.

[ssumpf]

@nfeske: Okay, will have a look.

[mewmew]

I'd also love to see libSDL2 support being added to Goa. Especially with the usability improvements of Goa in Genode 23.08. I can't wait to take it out for a spin for some hobby projects : )

@ssumpf thanks for working on this!

[nfeske]

I'm actually offering libSDL2 at my depot: https://depot.genode.org/nfeske/bin/x86_64/sdl2/ (x86) and https://depot.genode.org/nfeske/bin/arm_v8a/sdl2/ (64-bit ARM).

In your Goa project you can refer to my archive in your pkg/archives file using the concrete version nfeske/sdl2/2023-04-27.

It might be worth reviewing the directory https://depot.genode.org/nfeske/bin/x86_64/ for other useful archives, e.g., sdl_image is also there, which is often used by libSDL-based applications.

[mewmew]

That's great! Thanks Norman : )

Hope you've had a lovely summer. Did you do a Hack n' Hike this year?

happy hugs
/Robin & Daniel

[nfeske]

Hope you've had a lovely summer. Did you do a Hack n' Hike this year?

I spent my summer vacation completely analog, which was quite refreshing for the mind. Feeling nicely re-energized for the next Genode topics now. :)

We haven't had a Hack'n'Hike this year, but in my opinion we should definitely consider it for spring 2024. Would love to know how the others, e.g., @m-stein or @chelmuth, think about it.

[mewmew]

I spent my summer vacation completely analog, which was quite refreshing for the mind. Feeling nicely re-energized for the next Genode topics now. :)

Glad to hear! I too enjoyed some time in nature this summer. Went trekking in the Rocky Mountains in Canada, a long-lived dream of mine.

It's so great to see what you've managed to do with Genode since the first time we met all these years back. An amazing journey to follow <3

[mewmew]

Hi @nfeske!

I've had a blast experimenting with Goa and Rust. Thanks for publishing your sdl2 package to the depot.

I did run into some issues though with getting sdl2 running on the latest version of Genode. In particular, nfeske/src/sdl2/2023-04-27 relies on the legacy 'main' support which was removed in genodelabs/genode@e2836bf.

I currently get the following link time error when running programs linked against sdl2 (2023-04-27).

100 MiB RAM and 18997 caps assigned to init
[init -> hello_sdl] Error: LD: symbol not found: 'genode_argc'
[init -> hello_sdl] Error: Uncaught exception of type 'Linker::Not_found'
[init -> hello_sdl] Warning: abort called - thread: ep

[chelmuth]

It seems you have to build the sdl2 archive by yourself as libsdl2 was adapted in genodelabs/genode-world@9d779a3 too.

[chelmuth]

We haven't had a Hack'n'Hike this year, but in my opinion we should definitely consider it for spring 2024. Would love to know how the others, e.g., @m-stein or @chelmuth, think about it.

I'm very much for opening a Hack'n'Hike 2024 issue after a first offline brainstorming session.

[m-stein]

I'm very much for opening a Hack'n'Hike 2024 issue after a first offline brainstorming session.

genodelabs/genode#4989

[nfeske]

I did run into some issues though with getting sdl2 running on the latest version of Genode.

That's because Goa is officially tied to the most recent Sculpt version, which is not binary-compatible with the latest Genode version. So if you want to target the latest Genode, you'd have to create the package for libSDL2. That's not hard. You can find the pkg recipes for the src and api at the genode-world repository and use the following command to create it locally:

 genode$ ./tool/depot/create robin/bin/x86_64/sdl2 UPDATE_VERSIONS=1

Just on case you haven't already encountered them, I recommend exploring Goa's depot_dir and versions_from_genode_dir features (as described in goa help config) for targeting the latest Genode version with Goa.

[cnuke]

I spent some time to adapt the SDL2 support based on @ssumpf work and with the referenced commits I am able to build yquake2 as well as chocolate-doom with minor adjustments to the original cmake files (while make use of the provided cmake modules by each project).

[nfeske]

While porting SDL-based software and libraries, I encountered a few limitations of Goa.

• For SDL2 and the corresponding utility libraries, the include-search path needs to be extended to include/SDL in addition to the default include/ - same thing as for SDL1. Since the API-specific extension of the include search path is such a recurring pattern, we should better aid it by a utility function to avoid code repetition.
• The game Numpty Physics uses a plain Makefile w/o install rule. The game data is used as is from source. This became a problem when creating tar build artifact for this data. As the tar command operates in the build directory, it archived all those nice symlinks pointing to src/. Adding a --dereference to the tar command fixes that.

[nfeske]

@jschlatow would you consider the the commits of my sdl2 branch (https://github.com/nfeske/goa/commits/sdl2) for staging?

[cnuke]

@jschlatow Alright, it works in general but I had to make some adaptions depending on the host system. In my fairly old Debian 10 VM featuring cmake 3.13.4 using ALIAS for SDL2main in such a manner is not supported apparently. That being said, catering such an old system is bogus anyway.

On the other hand, my other system features cmake 3.27.6 but without commit 9872274 it always picks up definitions from /usr/lib/cmake, which results in the build failing for some targets. I noticed your commit b92f880 but that does not seem to make a difference for me.

Browsing cmake's documentation I was wondering if it makes sence for our use-case to ”explicitly” drive it in cross-compiling mode to prevent any cross-pollination.

[jschlatow]

On the other hand, my other system features cmake 3.27.6 but without commit 9872274 it always picks up definitions from /usr/lib/cmake

That is strange because commit b45cae7 should prevent this if I understood the implementation correctly. I had a similar effect though caused by cmake's caching. Only after removing the build directory, the aforementioned commit was effective for me. Have you tried removing the build directory?

[cnuke]

That is strange because commit b45cae7 should prevent this if I understood the implementation correctly. I had a similar effect though caused by cmake's caching. Only after removing the build directory, the aforementioned commit was effective for me. Have you tried removing the build directory?

Yes, I removed var/build several times while I was trying out different things - I started by specifying --debug-find to cmake and went from there. That's why I stumbled upon the different settings in the documentation and this one made it work for me.

[jschlatow]

Out of curiosity, does it help setting CMAKE_SYSTEM_IGNORE_PREFIX_PATH in addition to CMAKE_IGNORE_PREFIX_PATH?

[cnuke]

Out of curiosity, does it help setting CMAKE_SYSTEM_IGNORE_PREFIX_PATH in addition to CMAKE_IGNORE_PREFIX_PATH?

Also setting it to /usr/ makes no difference, does not work either.

[jschlatow]

Then we should probably disable all the CMAKE_FIND_USE_* options.

[cnuke]

Then we should probably disable all the CMAKE_FIND_USE_* options.

I'm on it.

[cnuke]

Well, the original commit 9872274 that mitigates my problem with one project breaks the linphone-sdk because now the required python interpreter cannot be found anymore for obvious reasons via find_program (after all cmake is now prohibited from checking $PATH to look up binaries).

After further consulting the documentation I see your point that ignoring the prefix should do trick, which leaves my puzzled why cmake picks my host's SDL2* config modules (or rather employs the Config mode to search packages) when $PATH is evaluated.

[jschlatow]

Looking at cmake's implementation, I noticed that the prefixes are compared before generating the search paths patterns. I.e. if your $PATH contains something like /usr/lib/cmake/(bin/sbin), cmake will still search the patterns mentioned here with /usr/lib/cmake as a prefix it is not ignored. Can you double check your $PATH and try setting the latter as an ignored prefix (which will automatically ignore /usr/lib and /usr as well)?

[jschlatow]

@cnuke I must correct myself, adding /usr/lib/cmake to the ignored prefixes does not imply /usr/lib and /usr. Also note that you must add --rebuild to Goa's command line when you test any changes in cmake.tcl.

[cnuke]

Alright, shame on me - I completely forgot that on voidlinux /lib is symlinked to /usr/lib, so cmake will pick up /lib/cmake via / from the truncated PATH entries; commit cf8a6e5 solves the problem for such systems.

Sorry for somewhat wasting your time on that problem.

For completeness sake I updated commit 940e01e but I am somewhat indifferent of including it.

[jschlatow]

Thanks for clearing up this mystery. I merged both commits to staging.

[jschlatow]

All fixes entered the master branch today. I also just pushed an example with commit 4fad395 on staging. It still references my modified api/sdl2 archive, though.