Unable to build on Debian Bullseye

[theofficialgman]

Since the latest release, marathon can no longer be built on debian bullseye

https://github.com/Botspot/pi-apps/actions/runs/10551299208/job/29228558713#step:7:3681

g++ -std=gnu++17 -DHAVE_CONFIG_H -I. -I../..  -I../../Source_Files/CSeries -I../../Source_Files/Files -I../../Source_Files/GameWorld -I../../Source_Files/Input -I../../Source_Files/Lua -I../../Source_Files/ModelView -I../../Source_Files/Network -I../../Source_Files/Network/Metaserver -I../../Source_Files/FFmpeg -I../../Source_Files/RenderMain -I../../Source_Files/RenderOther -I../../Source_Files/Sound -I../../Source_Files/TCPMess -I../../Source_Files/XML -I../../Source_Files -I/usr/include/libpng16 -Wdate-time -I/usr/include/aarch64-linux-gnu -I/usr/include/aarch64-linux-gnu -D_REENTRANT -I/usr/include/SDL2 -I/usr/include/AL -I/usr/include/opus  -D_REENTRANT -I/usr/include/SDL2 -D_REENTRANT -I/usr/include/SDL2  -D_REENTRANT -I/usr/include/SDL2 -DSDL  -g -O2 -MT ScenarioChooser.o -MD -MP -MF $depbase.Tpo -c -o ScenarioChooser.o ScenarioChooser.cpp &&\
mv -f $depbase.Tpo $depbase.Po
ScenarioChooser.cpp: In member function ‘void ScenarioChooser::optimize_image(ScenarioChooserScenario&, SDL_Window*)’:
ScenarioChooser.cpp:525:2: error: ‘SDL_SoftStretchLinear’ was not declared in this scope; did you mean ‘SDL_SoftStretch’?
  525 |  SDL_SoftStretchLinear(optimized.get(), &src_rect, scenario.image.get(), &dst_rect);
      |  ^~~~~~~~~~~~~~~~~~~~~
      |  SDL_SoftStretch
make[3]: *** [Makefile:486: ScenarioChooser.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/tmp/AlephOne-20240822/Source_Files/Misc'
make[2]: *** [Makefile:604: all-recursive] Error 1
make[2]: Leaving directory '/tmp/AlephOne-20240822/Source_Files'
make[1]: *** [Makefile:560: all-recursive] Error 1
make[1]: Leaving directory '/tmp/AlephOne-20240822'
make: *** [Makefile:454: all] Error 2

This function is only available in SDL2.16+ https://wiki.libsdl.org/SDL2/SDL_SoftStretchLinear . Please provide an alternative for older releases.

[Kangie]

On one hand, sure - This seems reasonable enough. On the other hand 2.0.16 came out in August 2021 is barely a point release past what Bullseye stabilised on - https://packages.debian.org/bullseye/libsdl2-2.0-0 (2.0.14).

If this were an official debian package, since the scenario chooser is a new feature, Debian packaging guidelines would say that it shouldn't be available on Bullseye and we're safe here.

If you're an end user just building your own Alephone I'd suggest getting your own libsdl2 and building against that.

You're a victim of Debian packaging, but you're also using oldstable; try bookworm which packages 2.26.5 and you should be fine.

[theofficialgman]

I'm well aware of debian versions and limitations of using something old. This isn't for me personally but pi-apps (see link) where we support the last two LTS releases of ubuntu/debian with all our projects where possible. This issue is simply a report because that is not possible for Aleph-One-Marathon due to the change.

[eli-schwartz]

This isn't for me personally but pi-apps (see link) where we support the last two LTS releases of ubuntu/debian with all our projects where possible.

And if it isn't possible, what do you do?

One option for what to do would be for your appstore to build an updated copy of sdl2 for use with the apps you distribute.

[theofficialgman]

And if it isn't possible, what do you do?

We hold the version of the application back and open a bug report.

One option for what to do would be for your appstore to build an updated copy of sdl2 for use with the apps you distribute.

Updating system dependencies is out of scope and can cause regressions (or: when features are removed or changed in later dependency versions).

There isn't anything wrong with an application statically linking sdl2 into the binary (ie: have sdl2 as a submodule and build it at the time of compilation) but it's up to the upstream developer (in this case, marathon) to provide that as an option in the buildsystem.

[eli-schwartz]

Updating system dependencies is out of scope and can cause regressions (or: when features are removed or changed in later dependency versions).

There isn't anything wrong with an application statically linking sdl2 into the binary (ie: have sdl2 as a submodule and build it at the time of compilation) but it's up to the upstream developer (in this case, marathon) to provide that as an option in the buildsystem.

But that's not what I suggested. I didn't say anything about system dependencies, I suggested that you might be able to build a static copy of sdl2 as part of the build recipe for applications that need it, and inject it into the build by augmenting $PKG_CONFIG_PATH or $SDL2_CONFIG (depending on which one the project in question uses) to point to the temporary copy.