ebiggers / libdeflate

Heavily optimized library for DEFLATE/zlib/gzip compression and decompression

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

import library name with mingw

vtorri opened this issue · comments

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")

commented

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.

commented

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.

any news on this ?

This (and many other handcrafted Makefile problems) should really be automatically handled by switching to either CMake (#101) or Meson (#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