-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
import library name with mingw #190
Comments
|
and the static lib has also the .lib suffix... 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. |
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 ? |
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). |
For the import and static libraries, use the MinGW naming convention (libdeflate.dll.a and libdeflate.a, respectively) instead of the Visual Studio naming convention (libdeflate.lib and libdeflatestatic.lib, respectively). The original assumption was that the native Windows convention was better. However, instead people expect the naming convention to reflect the toolchain with which the files were built. Also change 'make install' to install the DLL into the bin directory instead of the lib directory, again following the MinGW convention. Fixes #190
For the import and static libraries, use the MinGW naming convention (libdeflate.dll.a and libdeflate.a, respectively) instead of the Visual Studio naming convention (libdeflate.lib and libdeflatestatic.lib, respectively). The original assumption was that the native Windows convention was better. However, instead people expect the naming convention to reflect the toolchain with which the files were built. Also change 'make install' to install the DLL into the bin directory instead of the lib directory, again following the MinGW convention. Fixes #190
For the import and static libraries, use the MinGW naming convention (libdeflate.dll.a and libdeflate.a, respectively) instead of the Visual Studio naming convention (libdeflate.lib and libdeflatestatic.lib, respectively). The original assumption was that the native Windows convention was better. However, instead people expect the naming convention to reflect the toolchain with which the files were built. Also change 'make install' to install the DLL into the bin directory instead of the lib directory, again following the MinGW convention. Fixes #190
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 |
the import library name suffi is often .dll.a and not .lib. Agree to use
in Makefile ? If yes, i can do a PR
The text was updated successfully, but these errors were encountered: