`static_dynamicCRT` build still has dynamic link dependency for SDL2

[TheGag96]

Built what was basically the example project with the following dub.sdl on Linux Mint 20.3 (x64):

dub.sdl

name "imgui"
description "A minimal D application."
authors "<my name>"
copyright "Copyright © 2022, <my name>"
license "proprietary"
dependency "bindbc-loader" version="~>1.0.1"
dependency "bindbc-opengl" version="~>1.0.2"
dependency "bindbc-sdl" version="~>1.1.3"
dependency "bindbc-imgui" path="libs/bindbc-imgui"
subConfigurations "bindbc-imgui" "static_dynamicCRT"
subConfiguration "bindbc-sdl" "static"
versions "GL_33" "USE_SDL2" "USE_GL3"

This is the output of ldd imgui:

ldd output

	linux-vdso.so.1 (0x00007ffd4aa72000)
	libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f7309d78000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7309d72000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f7309cb3000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7309a99000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7309a76000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7309927000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f730991b000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7309900000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f730970e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f730a167000)
	libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f7309613000)
	libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f73095be000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f730947f000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f7309468000)
	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f730945b000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f7309456000)
	libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f7309444000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f7309437000)
	libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x00007f7309432000)
	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f7309429000)
	libwayland-egl.so.1 => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007f7309424000)
	libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f7309413000)
	libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f7309408000)
	libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f73093c6000)
	libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f730938c000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7309370000)
	libpulsecommon-13.99.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so (0x00007f73092ee000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f730929d000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f7309273000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f7309069000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f730905e000)
	libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x00007f7309052000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f7308fa3000)
	libwrap.so.0 => /usr/lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f7308f97000)
	libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f7308f19000)
	libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f7308d11000)
	libapparmor.so.1 => /usr/lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007f7308cfc000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f7308cf6000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f7308cee000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f7308cc5000)
	liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f7308ca2000)
	libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f7308b84000)
	libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f7308b67000)
	libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f7308b29000)
	libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f7308b1c000)
	libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f7308aee000)
	libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f7308a41000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f7308a25000)
	libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f7308a0b000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f73089e8000)

Am I doing something wrong here? Thanks!

[playmer]

That's intentional, but I was/am planning to eventually fix this.

The idea of the static_* configs is for cimgui to be statically linked. As it's not provided by distros (or well configured for our needs in Inochi, and we had issues with dynamically linked libraries on Linux.

I believe the default config for SDL on bindbc-sdl is dynamically linked SDL (correct me if I'm wrong), so it's easier for us to match that with our C++ dependencies.

We are planning to switch everything but the C/C++ runtime libraries to be statically linked, but I'm not sure how that will change our configs (do we turn this into a triplet that includes the permutations of SDL/Freetype?)

[TheGag96]

I see. It seems desirable to be as statically-linked as possible! This is a dub question more than anything else - is my line subConfiguration "bindbc-sdl" "static" in my project's dub.sdl actually doing anything? Or would I have to edit this library's too? Or is it just not configured for that at all right now?

[playmer]

Haha, that's the opposite of my expectation for most Linux programmers. I was under the impression most folks want their deps dynamically linked so their package managers handle them.

As for the sub configuration, here's where we start getting into headaches and part of why it's easier to link dynamically against our non-cimgui dependencies. When you specify that you want bindbc-sdl to be static, that will indeed do what you expect, specifically for those bindings. But bindbc-imgui needs to compile cimgui and imgui (the C++ dependencies) itself. That process doesn't know about the subconfiguration you've used for a different D dependency and uses whatever you've configured for bindbc-imgui, which currently doesn't provide any option other than dynamically linking.

Making sure the C++ libraries we depend on are the same as the C++ libraries other D libraries depend on are the same is tricky and not super clear how to do for every project. (Which I'm guessing is why most of the other D binding libraries probably default to linking against packaged stuff.)

That said, on Linux specifically, if we provided a config for "linking against SDL statically" you'd just need to pass that config and it'd be easy for all involved. We just don't have that right now. The first step was going to be compiling our own SDL and Freetype on Linux and figuring out how to make our AppImage happy with it, and then switch to statically linking.

[TheGag96]

Haha, that's the opposite of my expectation for most Linux programmers. I was under the impression most folks want their deps dynamically linked so their package managers handle them.

That's usually true, but I myself am super tired of the status quo of choosing between package manager hell or some heavy-handed packaging layer like AppImage, Flatpak, etc. Ideally, I'd like to learn how to make executables that I can copy between computers and have work (a tall order for modern Linux). Glibc and OpenGL as I understand probably have to stay dynamic for reasons... Though hopefully everything else should being static should help the situation.

[playmer]

I hear you. I'll try to figure something out soon. The easiest thing would be something similar to what we did with cimgui in the dub.sdl

Would you also want us to build our own copy of SDL? That's what we do on Windows and Mac, but I'm not sure how we could make that work on Linux as an optional thing without adding even more subconfigs. (Beyond what we'd already need to add configs for statically linking to freetype and SDL.

[playmer]

Wait, maybe I should generate our dub.sdl 🤯

[LunaTheFoxgirl]

SDL2 is probably not a good idea to statically link either since it's meant to be dynamically linked and be able to automatically switch to newer versions of the library on load.

Each distro should be seen as a separate operating system and it's your choice as a developer to decide which of those you want to support. Alternatively you should go back to the POSIX roots of shipping software & their dependencies in /opt, with rpath set to load from your /opt directory or just give up and accept AppImage.

This is over-complicating bindbc-imgui for honestly quite bad reasons, I feel we should even reduce the amount of configurations we have currently, as some make very little sense in the grand scheme of things. (eg. static-static) Unless we want to turn this in to a mix of a bindbc, sdl and freetype binding.

[TheGag96]

SDL2 is probably not a good idea to statically link either since it's meant to be dynamically linked and be able to automatically switch to newer versions of the library on load.

According to this, it seems like it's certainly a valid strategy (even if not one they recommend).

Each distro should be seen as a separate operating system
Don't you think this is kind of insane though?? These "different OSs" with the same kernel and most likely a lot of the same base software on it (perhaps different versions) are unable to share executables without some costly abstraction, just because we didn't want to statically link anything? This divide is an issue between releases of distros too... The releases page for mGBA gets me every time for how ridiculous the multiple Ubuntu downloads look.

In any case, I'm not convinced the reasons are bad, but I do understand that this may increase complexity on your part. Thanks for maintaining these bindings at all - good luck at whatever you guys choose to do.

[LunaTheFoxgirl]

Don't you think this is kind of insane though?? These "different OSs" with the same kernel and most likely a lot of the same base software on it (perhaps different versions) are unable to share executables without some costly abstraction, just because we didn't want to statically link anything? This divide is an issue between releases of distros too... The releases page for mGBA gets me every time for how ridiculous the multiple Ubuntu downloads look.

In any case, I'm not convinced the reasons are bad, but I do understand that this may increase complexity on your part. Thanks for maintaining these bindings at all - good luck at whatever you guys choose to do.

I don't, they are simply separate systems. And the issue isn't that things aren't statically linked, but that we treat all software installed by the package manager as system software, instead of separating system and user applications sensibly, giving each application the dependencies they need (like on Windows or macOS) through rpath and /opt, which is a POSIX path specifically meant to house software that isn't system software, but which is very under-utilized.