Skip to content
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

Closed
vtorri opened this issue May 28, 2022 · 12 comments · Fixed by #233
Closed

import library name with mingw #190

vtorri opened this issue May 28, 2022 · 12 comments · Fixed by #233
Labels

Comments

@vtorri
Copy link

vtorri commented May 28, 2022

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

@ebiggers
Copy link
Owner

.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.

@vtorri
Copy link
Author

vtorri commented May 30, 2022

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

@tansy
Copy link
Contributor

tansy commented Jun 9, 2022

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.

@ebiggers
Copy link
Owner

ebiggers commented Jun 9, 2022

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?

@vtorri
Copy link
Author

vtorri commented Jun 9, 2022

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.

@tansy
Copy link
Contributor

tansy commented Jun 15, 2022

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.

@vtorri
Copy link
Author

vtorri commented Jun 16, 2022

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.

@vtorri
Copy link
Author

vtorri commented Sep 11, 2022

any news on this ?

@vtorri
Copy link
Author

vtorri commented Sep 11, 2022

@kmilos
Copy link
Contributor

kmilos commented Sep 12, 2022

This (and many other handcrafted Makefile problems) should really be automatically handled by switching to either CMake (#101) or Meson (#191).

@vtorri
Copy link
Author

vtorri commented Sep 12, 2022

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

ebiggers added a commit that referenced this issue Sep 17, 2022
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
ebiggers added a commit that referenced this issue Sep 17, 2022
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
ebiggers added a commit that referenced this issue Sep 17, 2022
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
@ebiggers ebiggers added the bug label Sep 17, 2022
@vtorri
Copy link
Author

vtorri commented Sep 17, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants