Revisiting the idea of a single statically-linked DLL on Windows

[richardg867]

Discussions such as #851 and my own #1001 have been previously held about compiling FluidSynth with full static linking on Windows to remove the dependency on external DLLs. Those have been met with dismissal due to the following points:

• GLib not supporting static linking on Windows at the time. The landscape has since changed, with the merging of Windows static linking support into GLib in early 2022. The project I help maintain has successfully conducted tests with another GLib-dependent library (libslirp) using a statically linked GLib (both packaged by MSYS2) with no external DLLs.
• Replaceability of DLLs with the argument that there could be a bug in GLib or other dependencies which could be addressed by replacing the DLLs. My project strives to statically link as many libraries as it possibly can on Windows, to maximize the predictability of its user experience; if a library update is ever needed, our policy is to use our CI system to deliver new builds linked against updated static libraries. We've had issues of this predictability nature in the past, with libraries that were not statically linked misbehaving due to incorrect dependent DLLs being loaded (good old DLL hell), be it through a PATH issue, user error or otherwise.
• Maintainability. I don't see the argument to be made about maintainability in the first place; if FluidSynth doesn't do any weird dynamically linking shenanigans, it already provides a static option with dynamically linked dependencies, and it has provided full static linking support in the past, there's no reason not to support statically linked dependencies now.
• Other arguments which don't apply to everyone who wishes to statically link, such as licensing and MSVC compatibility.

With these arguments in place, I would like the maintainers to revisit the idea of full static linking on Windows. I hope this post made it clear where I (and others who also wished for this feature in past discussions) stand, and does not lead to a summary dismissal of the idea once again.

[derselbst]

I don't think I have ever dismissed the idea of static linking. It just wasn't technically possible on Windows because of glib. And I've expressed my opinions / concerns, which haven't really changed since then.

But ofc you're free to statically compile fluidsynth. Though, it's not quite clear to me what exactly you're asking. You seem to be asking for permission. Or is there something, that doesn't work as expected when compiling statically?

[OBattler]

From what I understand, he went to the MSYS2 repository and asked them for a static FluidSynth library but they told him they can only compile it with dynamic glib, so if I understand him right, he's asking for an official option to be added to compile static FluidSynth library with static glib. But he can explain better than I can.

[richardg867]

I do apologize for claiming the idea was dismissed outright.

When I compiled fluidsynth with -D BUILD_SHARED_LIBS=OFF on Windows, the resulting fluidsynth.exe still required dynamic GLib and OpenMP (but not fluidsynth itself as that is a static library), despite static versions of those libraries being present in the MSYS2 environment. Then I tried compiling my project against this same static fluidsynth...

find_package(FluidSynth CONFIG REQUIRED)
target_link_libraries(86Box FluidSynth::libfluidsynth)

...and while the CMake script did work and locate the dependencies, compilation resulted in many linking errors related to GLib and readline:

[...]
-- Found GLib2: C:/msys64/mingw32/lib/libglib-2.0.a (found suitable version "2.76.1", minimum required is "2.6.5")
-- Found DBus1: C:/msys64/mingw32/lib/libdbus-1.a (Required is at least version "1.11.12")
-- Found OpenMP_C: -fopenmp (found version "4.5")
-- Found OpenMP: TRUE (found version "4.5") found components: C
-- Found Readline: C:/msys64/mingw32/lib/libreadline.a (found version "8.2")
[...]
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/msys64/home/Richard/fluidsynth-2.3.3/build/src/libfluidsynth.a(fluid_settings.c.obj): in function `new_fluid_settings':
C:/msys64/home/Richard/fluidsynth-2.3.3/src/utils/fluid_settings.c:275: undefined reference to `_imp__g_rec_mutex_init'
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/msys64/home/Richard/fluidsynth-2.3.3/build/src/libfluidsynth.a(fluid_settings.c.obj): in function `delete_fluid_settings':
C:/msys64/home/Richard/fluidsynth-2.3.3/src/utils/fluid_settings.c:290: undefined reference to `_imp__g_rec_mutex_clear'
[...]
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/msys64/mingw32/qt5-static/lib/libqtmain.a(qtmain_win.o):qtmain_win.cpp:(.text+0x140): undefined reference to `qMain(int, char**)'
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/msys64/mingw32/lib/libreadline.a(display.o):(.text+0xdfd): undefined reference to `tputs'
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/12.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:/msys64/mingw32/lib/libreadline.a(display.o):(.text+0xe54): undefined reference to `tputs'
[...]

This is puzzling, especially with Qt also being dragged along. There is something going on with either fluidsynth or the MSYS2 packaging that is not allowing a full static build to work.

[derselbst]

Interesting. I don't have a definite answer right off. I would need to look into that, not sure when I'll find the time though.

Some thoughts that might help you:

• You could verify if the libraries linked against are the same as the ones specified as Libs.private in fluidsynth.pc. This ensures that all the libs explicitly specified in the pkg-config file are the same as the ones that CMake finds through its logic.
• You could try reproducing the problem by using vcpkg.exe install glib:x64-windows-static fluidsynth:x64-windows-static to figure out if it's an MSYS2 related problem or a general one.
• You could ping the author of CMake: Search for dependencies in FluidSynthConfig.cmake #1211 or Pedro, the co-author of CMake Modernizations #969 - maybe they've got an idea what's wrong.