Library extension G'MIC Prerelease 3.0.1

@David_Tschumperle

Bonjour,

After the compilation of the January 13 version the name of the library on Windows is libgmic.so.301

I really like the idea of putting the version in the name of the library.

Would it be possible to use the .so extension for Linux (libgmic.301.so) and .dll for Windows (libggmic.301.dll).

Merci :o)

I don’t know what the standard for naming dll files in Windows.

Most Microsoft DLL files that have a version number place it after the library name without any separator, e.g. the Microsoft C++ runtime files: msvcp140.dll, msvcp141.dll, etc.
libgmic301.dll would follow that convention.

Having multiple periods in a file name is generally avoided on Windows as it can make a file appear to have multiple file extensions.

1 Like

I see, then I’ll use that naming convention in next releases. Thanks!

That’s not an ideal convention either, as you have libraries that have a number in their name anyway, like e.g. libbz2, which would make it ambiguous to distinguish what is part of the version, and what is part of the name.

In the Mingw-w64 world, if you want add the SOVERSION to the dll, you would usually use a hyphen, so we have e.g.:

libarchive-13.dll
libbz2-1.dll
libpng16-16.dll

etc.

Also note that this is customarily done to distinguish major ABI changes in the library, so one doesn’t have to rebuild every time a minor/patch version is released, so I wouldn’t recommend putting the whole version in the name (on Windows). OpenCV does this for example, and it is very annoying (time wasting, environmentally not friendly, etc.) to have to rebuild everything depending on it for a minor version. On Linux this is not a problem because a major version symlink is created/maintained automatically e.g. libgmic.so.3 → libgmic.so.3.0.1 so it is always usable…

Finally, for many projects, the library ABI version (SOVERSION), at some point diverges and is independent of the project version…