FluidSynth MinGW packages do not contain unversioned link libraries

[madebr]

FluidSynth version

2.4.8

Describe the bug

The FluidSynth Windows MinGW package only contains versioned libraries.
It's not possible to link as -lfluidsynth, only as -lfluidsynth-2.

See the contents of the msys2 MinGW64 package:

/mingw64/bin/libfluidsynth-3.dll
/mingw64/lib/libfluidsynth-3.a
/mingw64/lib/libfluidsynth-3.dll.a

Expected behavior

FluidSynth should build a versioned libfluidsynth-3.dll binary,
and unversioned link libraries: libfluidsynth.a and libfuildsynth.dll.a

This issue was introduced in #1546
I think this should fix it:

-      ARCHIVE_OUTPUT_NAME "fluidsynth-${LIB_VERSION_CURRENT}"
+      ARCHIVE_OUTPUT_NAME "fluidsynth"

MinGW should have these files:

/mingw64/bin/libfluidsynth-3.dll
/mingw64/lib/libfluidsynth.a
/mingw64/lib/libfluidsynth.dll.a

Steps to reproduce

Build FluidSynth using MinGW toolchain, and try to link to fluidsynth using -lfluidsynth

Additional context

No response

[derselbst]

Yeah, I was pretty frustrated about the fact that there were three different library namings on Windows depending on whether it's a dynamic, static or import lib. So I consistently named them all the same. I'm failing to see why this is a problem. Could you please explain why -lfluidsynth-3 is a bug? The pkg-config file exposes the dependency correctly.

[sezero]

I'm failing to see why this is a problem. Could you please explain why -lfluidsynth-3 is a bug?

No one does -lfluidsynth-3, no unices do that, only win32. It is unusual and unexpected to say the least. And having such a change in advancing numbers of a release (>=2.4.6 as I understand it) is worse

The pkg-config file exposes the dependency correctly.

How about build systems that doesn't want to rely on pkg-config?

-lfluidsynth should be the norm, as it is so with all other libraries.

[madebr]

I'm failing to see why this is a problem. Could you please explain why -lfluidsynth-3 is a bug?

You want versioned libraries when you distribute binaries (dll's on Windows, .so's on Linux, .dylib's on macOS).
An external application linking to libfluidsynth-3.dll must be served an ABI compatible library, hence the library suffix to avoid conflicts with non-ABI compatible libraries.

This is also why you don't need versioned suffixed for import and static libraries: once you've linked your application to them, they are not needed anymore: they are now part of the external application.

[sezero]

This is also why you don't need versioned suffixed for import and static libraries: once you've linked your application to them, they are not needed anymore: they are now part of the external application.

Indeed: The dll itself being versioned (e.g. libfluidsynth-3.dll) is OK and good. But keep the import library unversioned because it will link the app to the correct dll already. (Similar for the static library.)

[derselbst]

So you're both claiming it's against some kind of convention. Fine. I'm a Linux user, I do not know about these conventions, and little do I care. For me, it's just a filename that I wanted to keep consistent no matter what build configuration you choose on Windows. There were several other people involved in the mentioned change, nobody objected, so I considered this just fine.

Admittedly, I can't really comprehend why people are not using (or rejecting) the help offered by buildsystems like pkg-config or cmake itself, and then complain about a naming of a library filename.

If you want to change it, please submit a PR against master with the desired change, so this can be released with 2.5.0 in October hopefully. I won't be the one to implement such a change. Frankly, I'm quite tired of this topic, esp. when having to read comments like "[...] sh^w^w thing [...]" or "Geez.. Where the hell did they get that idea."