Best way to build and deploy SDL applications?

[electrosys]

Hi Everyone,

I can use help understanding the best way to build and deploy SDL applications. Should the application be built statically or dynamically?

I currently build the Linux version of my app using the sniper docker image in the Github Workflows automated build system. I’m using g++ and make.

I’m trying to get the windows version of the app to build in workflows as well but I have run into an issue where a call to SDL_QueryTexture() silently closes the application. I can build the windows version locally on my machine without issue, dynamically. I’m using SDL2 and Mingw on windows.

Anyone with some expertise on building and deploying able to offer some insights?

Also if you would like to take a look at my make file: sdl2-blocks/makefile at master · electrosy/sdl2-blocks · GitHub

[yataro]

@electrosys

Should the application be built statically or dynamically?

It depends on what you want (and on how your app and dependencies are licensed). In my opinion dynamic linking is preferred for many reasons, including ability to replace ABI stable dependencies with newer versions without recompilation. In the other hand static linking allows you to get single-file executable, less disk space used by app (on Windows you usually bundle dependencies on app basis) and optionally benefits of LTO.

@electrosys

I’m trying to get the windows version of the app to build in workflows as well but I have run into an issue where a call to SDL_QueryTexture() silently closes the application. I can build the windows version locally on my machine without issue, dynamically. I’m using SDL2 and Mingw on windows.

SDL_Texture* ley::Textures::getTexture(std::string s) {
    return textures.find(s)->second;
}

It’s probably find(s) that returns textures.end() here and getTextures that returns invalid pointer. You need to debug the app to find out why.

[electrosys]

@yataro

It’s probably find(s) that returns textures.end() here and getTextures that returns invalid pointer. You need to debug the app to find out why.

That’s a great point. I added some logic to return if the texture is not found and your absolutely right, it can’t find the texture.

I’m completely dumbfounded though as to why it works on Linux both locally and on GitHub Workflows. On Windows it works locally but fails to work when I build using the GitHub workflows. Maybe a case issue or something. I’ll keep digging.

Thanks so much for your help, you completely nailed it.

[electrosys]

It appears that the issue was related to JPG not being supported in the build that I had.

This was fixed by adding ‘libjpeg-turbo’ to the sdl2-image install sdl2-image[libjpeg-turbo] . I’m still a little fuzzy on how and why this works. Note that my code does not make any calls to IMG_Init().

Should my code be making a call to IMG_Init()? Anyone familiar with Github workflows that can help me better understand if my workflow is the best way to handle building an SDL application?

.github/workflows/build-windows.yml

Thanks,
Electrosys

[yataro]

@electrosys

This was fixed by adding ‘libjpeg-turbo’ to the sdl2-image install sdl2-image[libjpeg-turbo] . I’m still a little fuzzy on how and why this works. Note that my code does not make any calls to IMG_Init().

SDL_Image loads image formats dynamically, so if the needed library is missing, SDL will fail to load image format. You need to properly handle errors and log SDL error messages. You can utilize C++ exceptions for this.

@electrosys

if my workflow is the best way to handle building an SDL application?

The best way is the way you find the best. For me the best way is to use MSYS2 to fetch SDL and its dependencies, I also use it to build and publish Windows application.