How can I get mingw to emit .lib instead of .a static libraries on windows?

[ThatNerdUKnow]

Hello all, I am trying to build this library that only seems to build on the mingw toolchain, and by default the build is generating .a static libraries when I need it to generate .lib static libraries. It's my understanding that you can't really mix libraries distributed in msvc style libraries .lib, .dll and mingw style libraries .a, .so.

Here's what my native file looks like

[binaries]
c = "gcc"
cpp = "g++"

Would the archiver be the way I get one type of library to generate vs the other?

This is coming from an issue i'm having compiling a rust library that links to two c libraries. One library is distributed using .lib and .dll libraries while the other isn't distributed anywhere and I have to build it from source, hence why I'm trying to get them to play nice together.

When I use the mingw toolchain in rust, I can't link to ffmpeg, while if I use the gcc toolchain I'm able to link to ffmpeg, but can't link to this library I'm building from source cause I'm mixing and matching compilers?

[eli-schwartz]

This is documented as the name_suffix: kwarg at https://mesonbuild.com/Reference-manual_functions.html#library

Note that the filename suffix has nothing to do with the ABI you're building for and the tooling doesn't care. Windows doesn't have significant filename extensions and you have to name the exact file you're linking to anyway. It's an acceptable filename to use even when building MSVC-style libraries.

Note also that you can mix GNU and MSVC libraries, you just have to use the ucrt for mingw (this should be the default these days). Many people do so, @nirbheek for example can attest to this for gstreamer.

[ThatNerdUKnow]

So is this name suffix something I can override as a command line argument or as an option in a native file? I'm wanting to set this behavior without editing the original meson file cause the library i'm building from source as part of this build script for my crate is a vendor library, so I'm kind of at their mercy for the most part for how their project builds.

[eli-schwartz]

Meson has rust language support and IIRC rust guesses at filenames similar to how GCC does (but MSVC does not). Meson handles this by using -C link_arg=path/to/libfoo.a instead of -l static=foo.

I have no idea how this is handled with other rustc users. Maybe cargo should handle this, maybe it does handle it, no idea.

[ThatNerdUKnow]

Hmm, Yeah I think you might be on to something there. So I would link to the lib explicitly for the library i'm building from source rather than relying on link search and link lib in the rust build scripts

[ThatNerdUKnow]

I also feel that I should make it clear that I'm only using meson as a build system for this vendor library I want to link to ( I had to fork a crate that has bindings to meson's CLI options) and I'm doing so using the rust build scripts which are rust's way of doing some set up work like bindgen stuff and linking to external libraries

[eli-schwartz]

Sure, makes sense. :) I just mentioned Meson's rust support for context on how Meson solves that problem. I don't know much about rust myself, but I do have a bit of knowledge about how our (Meson's) resident rust contributors have made use of rust.