Is it possible to build a single Windows DLL that includes glib, gthread ect. dependents?

[jabza]

Hello,

Sorry if this is a dumb question. I have successfully built the FluidSynth 2 dll on Windows using Visual Studio. However, I notice that the dll is dependent the existence of a few other dlls (glib, gthread, ect) in the same directory.

Is it possible to a self-contained 'libfluidsynth-2.dll' which statically links these additional libraries, and if so, how would one go about that? I'm curious if this was done in older versions.

I found a tool by Microsoft called ILMerge that can combine DLLs, but that only appears to work with .NET binaries.
Any help with this would be much appreciated!

Thank you :)

[derselbst]

Yes, it is possible: You just have to go through every dependent library of libfluidsynth.dll and compile that dependent library from source to create a static .lib. But before you can do this, you would have to build static versions of the dependencies of those dependent libraries. And before you can do that, you need to compile static versions of the dependencies of the dependencies' dependent libraries... you see the recursion stack that is building up until you finally end at Windows' native dlls, which you will be forced to link in dynamically.

Also, when performing static linking you must pay super close attention to software licenses: If you accidentally statically link in a GPL licensed software, libfluidsynth will also become GPL. If you then link libfluidsynth into your proprietary application, you would commit a GPL license infringement (no matter if linked dynamically or statically).
Or: if create a static version libfluidsynth (entirely made of LGPL libs) and you then statically link that libfluidsynth.lib into your proprietary software, you would commit an LGPL license infringement, as described in the wiki.

And if you then find out that the version of glib, gthread, libsndfile, whatever, contains a bug, you can happily go through that compilation process again. Whereas in the dynamically linked world, you would just copy+replace a single dll file.

Because of that hassle, static linking is usually discouraged.

[jabza]

Thank you for the detailed reply! Good points regarding the maintainability and license of such a build.

I would be linking only immediate LGPL compatible dependencies into libfluidsynth.dll. The reason I ask is I have an older FS .DLL that appears to have been built like this upon inspecting it.

Interestingly, I assume when fluidsynth.exe is statically built (with possible GPL libs?), this doesn't violate FS's LGPL, rather, requires the .exe source itself to adhere to the correct license.

Thanks again.

[sykhro]

Besides the hassle explained above, you'll find that you can't actually do this because at the time of writing GLib doesn't support static compilation on Windows. All efforts to enable this that have been proposed upstream so far are stale and/or abandoned. Until someone steps up and implements what's needed, this can't be done.

[derselbst]

Aha, ok.

[MrSapps]

yep its pretty annoying to need such a huge dep 😔

[3119369616]

Here is my 64-Bit Binary (Single DLL):
https://github.com/3119369616/fluidsynth/releases/tag/v2.2.7

[derselbst]

How did you manage to link in glib, as glib cannot be linked statically on Windows?

[3119369616]

GLib can be linked statically!
I used the flag --static in CMAKE_SHARED_LINKER_FLAGS to let GCC link the static libraries in the DLL. This operation would cause errors like "Undefined references to XXX" and then I appended some flags like -l<libname> to link depended libraries which were corresponding to the errors. Now this DLL doesn't depend on any other DLLs.
The library names I appended:
-logg -lflac -lvorbis -lvorbisenc -lffi -lopus -lpcre -liconv -lssp -lpsapi

[sykhro]

Please note that this is using the GNU ABI and winpthreads. The resulting library cannot be linked against when using MSVC.

[kmturley]

Do you have the full list of commands you used to install/build your Windows binary?

I would like to replicate the commands in GitHub CI:
#1140

[3119369616]

Please note that this is using the GNU ABI and winpthreads. The resulting library cannot be linked against when using MSVC.

I am using MSVC, too, nowadays. I built a very simple program successfully by myself, named fluidtest.c:

#include <fluidsynth.h>
int main()
{
    fluid_settings_t *settings = new_fluid_settings();
    delete_fluid_settings(settings);
    return 0;
}

I used the command line cl.exe fluidtest.c /Ie:\fluidsynth\include /link e:\fluidsynth\lib\libfluidsynth.dll.a (VC++2022, also called as MSVC v143) to build it.

The C ABI is __cdecl and it can be used by both MinGW-w64 and MSVC in usual, so your trouble is not about ABIs.
Perhaps you used the wrong CPU architechture. To link against libfluidsynth, you must use x64 native instead of x86.
Last note: My DLL did not depend on libwinpthread.