libdeflate
libdeflate copied to clipboard
ebiggers
import library name with mingw
the import library name suffi is often .dll.a and not .lib. Agree to use
SHARED_LIB_LDFLAGS := -Wl,--out-implib,libdeflate.dll.a \
in Makefile ? If yes, i can do a PR
.lib appears to be the Windows convention, e.g. see https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-creation#creating-an-import-library. So I'm thinking it shouldn't be changed.
and the static lib has also the .lib suffix... that's why dll.a is better. also the name says that it is explicitely a file related to the dll.
anyway, do what you want until the link is correct when linking with ld (see https://sourceware.org/binutils/docs/ld/WIN32.html section "direct linking to a dll")
All libraries in all mingw distributions I have (from 3.4 to date) use "*nix" convention (`.a', `.dll.a'). Even rust guys recognise that: Windows: Static libraries should end with .a not .lib when using MinGW/GCC.
I thought that the point of providing an import library is because Visual Studio requires it in order to link to the DLL. (MinGW does not require it.) So doesn't it make sense to use the Windows naming convention for it?
import lib is not necessary for a DLL with VS, you can use a def file (https://docs.microsoft.com/en-us/cpp/build/reference/module-definition-dot-def-files?view=msvc-170). def files are also supported with ld.
because Visual Studio requires it in order to link to the DLL doesn't it make sense to use the Windows naming convention for it?
Yes, if this particular naming (.lib) is required. If VS can accept mingw naming (.dll.a) then keeping it makes sense to indicate origin, mingw here. It seems that mingw-gcc can accept VS lib; don't know about opposite direction. It's apparently true for dynamic libs only, not static.
I have just tried with zlib (import lib : libz.dll.a) and the function zlibVersion(). The program compiles and links with Visual Studio, and prints the zlib version when I execute it.
btw, msys2 patch: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-libdeflate/001-libdeflate-makefile-mingw-fix.patch
This (and many other handcrafted Makefile problems) should really be automatically handled by switching to either CMake (https://github.com/ebiggers/libdeflate/pull/101) or Meson (https://github.com/ebiggers/libdeflate/issues/191).
my personal preference is by far meson. If there is a preference for meson from maintainers, i can try to write it (I've already written meson files for my personal projects).
note that meson automatically deals with the dll/stattic lib extensions (unix, mingw, VS) without hack. It aulso installs automatically the dll in $prefix/bin on mingw