[SDL_gfx] [SDL2_gfx] [SDL_mixer] Wrong filenames for dlls in these packages

[hgdagon]

Currently, the packages contain dlls with the following names:

libSDL_gfx-16.dll
libSDL2_gfx-1-0-0.dll
libSDL_mixer-1-2-0.dll

This is inconsistent with all other SDL dll names. Should be renamed to:

SDL_gfx.dll
SDL2_gfx.dll
SDL_mixer.dll

Note that the SDL2_mixer package does not have this issue.

[Biswa96]

What you are asking, the opposite of it is desirable. Generally, the number after DLLs name specify the version number of that library. If that number is changed we can get an indication that the dependent packages also have to be re-built. For example, here is the file list of sdl2_gfx package in ArchLinux.

$ ls -l /usr/lib/libSDL2_gfx*
/usr/lib/libSDL2_gfx-1.0.so.0 -> libSDL2_gfx-1.0.so.0.0.2
/usr/lib/libSDL2_gfx-1.0.so.0.0.2
/usr/lib/libSDL2_gfx.so -> libSDL2_gfx-1.0.so.0.0.2

The actual shared object file (distant cousin of DLL) is with version number.

[lazka]

hm, but our .pc file is wrong then, right? (note SDL, not SDL2)

$ pkg-config.exe --libs SDL_gfx
-LC:/msys64/mingw64/lib -lSDL_gfx -lmingw32 -lSDLmain -lSDL

[Biswa96]

Looks like yes.

[hgdagon]

@Biswa96 The other SDL dlls in the MSYS2 repo, and, most importantly, the releases on the official website(s) don't have version numbers or the 'lib' prefix in their filenames. Shouldn't we try to stay close to the official releases? Right now these are the black sheep of the bunch.

[Biswa96]

I'm not sure if it breaks any dependent packages. Generally, autoconf searches those lib- prefix. @Alexpux may proivde some insights. We had a talk about this version numbered DLL somewhere (I forgot it).

[revelator]

mostly a problem if you have multiple versions of the same dll in PATH, since neither msys2 nor mingw-w64-* are in PATH and we only use one version eitherway i dont see a problem. That in mind i would discourage creating software using these if you intend them to be on PATH.

[mingwandroid]

@Biswa96 The other SDL dlls in the MSYS2 repo, and, most importantly, the releases on the official website(s) don't have version numbers or the 'lib' prefix in their filenames

No, we do not attempt to follow upstream decisions on file-naming. Their decisions come from a very different place than where we are at since we are concerned about overall consistency rather than upstream's whims (or in the case of DLL naming, upstream's arbitrary decisions to change things on Windows). We prefer the Linux/macOS approaches which are hard-coded into GCC (so when you pass -lfoo to GCC, even on Windows, it looks first for libfoo, as it should).

Given that DLL hell is real, if we do use different names from official releases then we are immune to DLL hell vs upstream DLLs.

On Windows, upstreams by-and-large expect things to get installed into C:\Program Files, and for all DLLs to be beside the program they are used by. This isn't something MSYS2 cares for. Heck, we even deliberately adopt Linux FHS standard layouts for things when we can, simply because it is better organized that way.

[mingwandroid]

.. if anything I would prefer to see upstream aligning their windows file layout with the other systems and we prove that is workable.

[revelator]

One standard would indeed be much appreciated :)