Windows Library naming conventions #8153
Comments
|
Just for reference: vcpkg is renaming all static libs to follow the native naming on windows because otherwise CMake and Autotools +pkg-config are completely broken. Since it breaks pkg-config it also breaks meson itself. |
|
related to #7378 |
|
I think the explanation for the conscious choice why things are the way they are is pretty good, but while it solves the collision of import-vs-static libs, it introduces a new collision for artefacts with a mingw ABI vs. MSVC ABI, which is what people are running into, now that the CMake 3.25 has been released, which considers But I was wondering why it has to be How about CC @eli-schwartz, I saw you commented on reddit about this. There have been more comments about this on the CMake PR. I don't have a horse in this race, except that - all things considered - I'd prefer more projects to add support for meson (and the breakage caused by this isn't helping that goal particularly AFAICS). |
|
Relevant: CMake has reverted the change to look for |
|
Does anyone have a proposal for a naming convention that would fix this issue without causing breakage in other cases. IIRC Rust has a different naming scheme for their libs but I don't remember the details (and I looked at that ages ago, maybe it has changed since). |
See above:
AFAICT, it should be enough choose a different file extension other than vanilla |
|
Part of the reason for originally choosing I suppose it's not beyond reason for them to add a third (and maybe even popularize convention between meson, gcc, and cmake to fix this problem once and for all). |
Is building on mingw with meson a common usecase (much less mixing in artefacts produced by MSVC)? It seems to me that mingw tends to stay in its own distribution bubble much much more than a cross-platform build tool like meson ever could, so reusing meson-built artefacts in mingw seems to me to be the least widespread1 usecase to sacrifice here... OTOH, with the speed at which things diffuse in mingw-land (at least from some limited experience), I wouldn't expect a third way to find libraries (even if released today) to be broadly usable before 3-5 years, and presumably this situation should not stay in limbo that long... Footnotes
|
Yes, because that includes both cygwin and MSYS2 runtime layers. :) (much less mixing in artefacts produced by MSVC)? That's a better question. The answer to that is "I dunno". It's definitely done at least sometimes. @nirbheek can speak about gstreamer usage, for example. If I had to take a completely wild guess, I'd guess that people who do development with a mingw compiler are significantly more likely to mix the two than people who do development with a MSVC compiler, though! ... Due to the first part, it's absolutely, unquestionably correct to continue using mingw naming when running the mingw compiler. :D Fortunately, that part is easy to Due to the second part, it might be plausible to use If we did do that:
|
|
(FD: CMake developer) FWIW, I don't find the "but it makes |
|
That's unfortunately totally broken, because full paths hardcode one or the other of static vs. shared libraries. I do understand that shipping static and shared isn't a use case supported by cmake, so cmake's approach is internally consistent, but... it doesn't work generically, it's a practical problem for Unix users, and it's technically wrong for Windows as well even if in practice windows users often only bother building whichever linkage model will be used by the next step in the application they are currently building without a system library framework. (But that doesn't mean Windows users never want both!) Decomposition can't ever find the wrong thing if you do manual searching instead of letting the compiler interpret That doesn't mean we can't do better! ... We could even call it "CPS" or something. :p But that is overly verbose, has way too much focus on things people don't need, doesn't nicely handle common pkg-config use cases, like dataonly, and making yet another tool instead of version 2.0 of an existing tool implies making a third ecosystem. (Freedesktop pkg-config is effectively dead. Everyone tends to use pkgconf instead, these days. The pkgconf developer is interested in incrementally improving |
|
(Note also that you still want to be able to emit the flags as |
your approach is already broken so ..... (in exactly the same way on windows) pkg-config has the cmd line switch
that statement is wrong. I see a lot of upstream building both. The difference is that it requires explicit targets to do so instead of implying it.
You don't mean
libtool already breaks if you try to mix static and shared libs in the lookup unless you explicitly pass |
No, I mean the ecosystem which that's an entry point to. The user generated part is broken, and the cmake generated part is also broken.
No. I mean libtool was breaking when using all shared libs all the time everywhere, if the shared lib is specified via a path instead of (Why, I could not tell you.) |
Any specific link should? One already needs to change the link line when switching, so why is this not suitable?
It's not something supported through a "config" change (i.e., release vs. debug), but projects do indeed do this.
Decomposition can fail with:
where
Yeah, CMake's config files use syntax that is not trivial for anything else to understand. I don't think it's the long-term solution for interop myself either (though I'd be surprised if CMake didn't convert whatever it reads into that format for a long overlap period). As for What I do not want to see is continuation of the "flag soup" that we have today. Not all compilers share flag spellings or even support the same features. There are requirements that depend on usage (e.g., "link to libpython if you are an executable or a plugin not being loaded by something necessarily already aware of Python, otherwise tell the linker to ignore undefined symbols" is not something I think one can express in a |
We didn't ignore it. We don't use it because it has (had?) a bug where it would blindly put the
This is actually exactly the case that Meson handles better than most other build systems. If you wanted to pull libA and libB from two different prefixes and they have pkgconfig files, then you'd get: If you don't do decomposition, you get a linker line like: Which will actually put And if you call Like you say, we only have the command-line to communicate with the linker, so it is up to us to provide APIs for the user to communicate to us (the build system) what they want to do, so we can make sure that the linker does the right thing. Now, why is it a benefit to have libraries that can be found with For example, if a Rust crate wants to link to your library using a pkgconfig file (which is something gstreamer, gtk, glib, etc use for Rust bindings), then the build system will need to parse the pkgconfig output and pass it to
GNU / MSVC is actually a false split. The actual split is:
If you want to link libA with libB, if the two are C libraries, all you need to check is what CRT they are using. If both are using MSVCRT or UCRT then you're fine. Else, you can still link them but you need to be careful about memory management: https://learn.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries If you want to link libA with libB, if the two are C++, they must be built with the same C++ std and ABI, which means they must be built with the same major compiler version. IIRC MSVC breaks C++ ABI across compiler versions, and each C++ std has a different ABI. Also both must be linked to the same CRT. So, the actual fix that cmake (and meson!) should employ is to check whether the static library contains only C objects, and in that case just link them together if they use the same CRT. And if it contains C++ objects, also check whether the C++ ABI is compatible. |
This comment was not about meson but outside meson. E.g. generating link lines from pc files for e.g. msbuild.
that shouldn't happen and means the pc file is incorrect. |
|
(I cannot comment on the cmake MR because I cannot seem to find my gitlab.kitware.com password, and I'm not sure how I originally created that account but my current email address isn't getting recovery emails but also seems to say it's already in use. Sorry for discussing this in the wrong place.) I wonder if maybe the correct long-term solution for CMake is to check for
I don't know if CMake is set up to make this split between explicit vs. implicit prefixes, but if it could be done then CMake would once again be able to detect Meson-built static libraries, but also autotools ones and, I believe, the ones cmake itself creates when told to use the mingw GCC compiler (and the UCRT as a default CRT). What do you think? |
I was thinking along those lines too, and have opened CMake Issue 24216 to discuss dropping the PATH-derived search prefixes. |
|
This also affects using Meson-built libraries from Rust, which hardcodes the MSVC ABI to expect .lib: https://github.com/rust-lang/rust/blob/2ceed0b6cb9e9866225d7cfcfcbb4a62db047163/compiler/rustc_target/src/spec/windows_msvc_base.rs#L15 |
|
I was not aware of this thread, and there is indeed something to do in Rust as well... rust-lang/rust#114013. FWIW, I find Rust's |
|
So rustc produces import libraries that are unusable by mingw GCC which is otherwise capable of linking together mingw+ucrt libraries and MSVC libraries? It is not clear to me why this is an advantage... |
|
I haven't followed the whole thread here, what's the TL;DR? When doing In the likely case there is no intersection, I think ultimately the decision needs to come from the user. Only they know how that lib will be used, so we probably need a global Sorry if I miss the point here, I'm new to this topic, trying to understand. |
Also try searching mesonbuild/build.py for "libfoo". |
|
Oh, point 6 there is the part I missed, thanks.
You mean that with GCC -lfoo won't find |
I'm talking specifically about Microsoft's MSVC, haven't gotten round to testing GCC here. MSVC cannot find Meson generated libraries. Not because they're wrong in format; rustc tells LINK.EXE that they have the .lib extension (as per the TargetOptions, and per MSVC's own standard), but Meson does that rename to avoid the name clash. This is not detected in any way by rustc, and cannot be handled by Meson except by going over every single dependency and setting the |
|
@xclaesse @eli-schwartz Once more, my remarks so far only cover the MSVC compiler -- I've not tried to build gst-plugins-rs with MSYS2, so I cannot comment or offer any insights yet. |
MSVC cannot find libraries, it doesn't implement the concept of searching.
rustc can tell LINK.EXE whatever rustc wishes to tell it -- and rustc will have to tell it that they have a MSVC doesn't have a standard, period, so that shouldn't be a problem. |
You can use the #[link(name = "mylib.a", modifiers = "+verbatim")
extern "C" {
fn bar();
} |
This is completely incorrect. I build static libraries alongside shared libraries all the time in my projects because I link my libraries statically into their test executables. I am not alone in this practice either. |
Correct, it hasn't changed recently.
Wrong, because it is usable...
I don't think it makes sense to imagine that "what windows-rs does" can be generalized to all cases. You keep saying that mingw GCC didn't "used to" be able to do things that people have been doing for a very long time (probably longer than rust has existed) but it's not clear to me what that's based on -- I suspect concern that it can't be made foolproof, so better to forbid anyone from doing it no matter how much they beg to be allowed and insist they know what they are doing? What's gotten better is that modern Windows has the UCRT, and modern mingw can target the UCRT, which means better standards conformance and less need to take care in writing your source code to specifically cope with fragilities that were for a long time part of what people doing this sort of mixing considered to be a standard and accepted requirement of doing so safely. Note that this mixing was always opt in, not opt out... you had to actually install both toolchains and add search paths of one into the other.
My understanding was that it's considered widely accepted practice on Windows to have one define, not two, and a number of projects from the Unix world specifically arranged for that to be the define for linking statically for exactly this reason. (There's some interesting insight in libass/libass@c5ee66d, which points out that for simplicity some projects which only care about functions, totally ignore dllimport and eat an object pointer cost in order to ensure that linking works no matter what.) But either way I suspect it's very much a non-issue, you can just do both. Stick Sure, more options can be added to make that prettier. But it's no hard blocker. |
For what reason are you doing this? In the worst case you are not testing the same generated code you are deploying.... |
Do we have a specification on how flags should be put together? Because if the order here is flipped, things don't work. Just to note, this is my general unhappiness with |
|
I'm not the one who's going to defend pkg-config, it has no formal spec, it's implementation is terrible and most projects get it wrong. But there we are, it is so widely used across OSS that we can't ignore it, and we can barely even improve it... Until at least all major distro switch to pkgconf, looking at you debian... Regardless, back to original topic, I think requirement for a naming convention are:
Current status:
Did I miss something? |
Arguing with you has proven to be a waste of time on multiple forums. |
Nope I think meson could do better. I mean somebody already suggested different folders so why not have different output folders on windows like shared/static on build time and decide what to actually install on install time. The static test linkage tristan957 mentions seems more to be a build time thing instead.
Strictly speaking pkg-config on windows is not really a thing unless you use MinGW and than the naming issue doesn't really exist. It works yes but since there is no defined directory layout pc files always struggle with relocateablity if not explicitly fixing the prefix. MSVC also has to differentiate between debug/release CRT which pkg-config simply cannot do. (How does meson even want to fix that dilemma btw?). This also has a unsolved naming conflict which hasn't been broadly discussed yet. So there is not only the static/shared name conflict but also the release/debug name conflict. I mean vcpkg solution is quite straight forward here. Only allow one library type and one configuration type per project/prefix.
Yeah it gets is increasingly difficult to argue with me if you don't have any good arguments. |
It is one of many uses. It's also standard in many places to, well, ship both so that people can make their own decision which to use. Obviously, this is Unix exclusive behavior, because building libraries in advance once and distributing them to many people is a Unix exclusive urge... but that's convention and the desire to be useful to downstream users, not a hard requirement...
What? No. This is totally false, although also totally typical of people who hate pkg-config so much that they'd rather be unable to use it effectively than give up the opportunity to complain about it every chance they get.
Okay. So do that. Run meson once per type, and install it with different relocatable prefixes. MSVC can then differentiate all it wants between debug/release and static/shared and any combination thereof. It's certainly a style choice of some sort. But there's nothing stopping you from making it. However, installing different prefixes for each type of library does mean that you'll need to build all code generators, data, binaries, etc twice and install them twice or you simply won't have them available for use inside of totally different prefixes, which seems particularly unfortunate for something as easily solved as naming static/shared libraries with names that allow the build system to distinguish between the two when using |
|
For example, GStreamer project ships prebuilt development kit that contains both But they provide different MSI that install into different locations for MSVC/Mingw and 32/64bits: https://gstreamer.freedesktop.org/download. An app developer would build their Meson project with I'm not saying that's a hugely important use-case, clearly not how most project distribute for Windows, but it's a use-case that exists and we can/should support. |
I think this was more driven by technological limitations of the past which nowadays seems to generates more issues than it solves by having "seemingly" outdated stuff if you don't build yourself anyway.
So how many packages generate pc files that actually install using
vcpkg has host-triplets and code generators are only build for the host and not for the target (if it at all can be deactivated). This means packages with code generators have a host dependency on themselves to build the actual code generators. (vcpkg forces meson to use None.txt as a native file). But IMHO projects should only focus on the target architecture for better modularity, but that is a totally different discussion.
again you neglect debug/release configuration which is the only one CMake needs to be able to distinguish on MSVC. Since a lot of projects don't add debug suffixes to debug builds it is basically impossible to do that without using different prefixes. Furthermore CMake uses cache variables so you can to explicit set it if necessary.
gstreamer uses meson.... again a cyclic argument. The MSVC gstreamer build in vcpkg actually renames the static meson output to reflect MSVC default behavior.
|
|
@Neumann-A I think there is a reason why mixing static/shared in a build makes sense, but not mixing debug/release or different ABIs. It is because you can make both shared and static libraries out of the same .o objects without recompiling. Arguably it's rarely the case for Windows (but not impossible), but it works on all other platforms, which makes it a not so niche use-case. If you make different ABIs, or debug/release builds, you have to recompile everything twice anyway, so better install into different prefix.
Why are they doing that? AFAIK that's because CMake's fine_library() won't find Also, isn't it already working for CMake projects that relies on pkg-config file generated by Meson anyway? |
As I said the pc file for gstreamer is broken for static linkage for MSVC without renaming (cli: |
|
I don't think they are broken, I think they rely on the fact that Meson will resolve I know that this sounds like Meson imposing its convention on CMake, but it really feels like Meson does have a better proposal with strong rational. Is there really a downside in adopting that convention if CMake is willing to do it? |
I haven't done a study on the topic. I do know for example that this is one of the reasons meson recommends using the builtin .pc file generator, since it can get this correct automatically.
Sounds like quite a bit of work which is then ignored half the time by projects that don't support it. But it also misses the issue of built artifacts that aren't C/C++ libraries. e.g. common in toolkits.
No, I didn't ignore it, I said that instead of 4 prefixes one for each combination I think it makes sense to have two prefixes for debug/release configuration and then
would allow having each of those two prefixes "easily solve" the static/shared split by providing both in one prefix.
This is not a cyclic argument??? The argument is that people who use meson or autotools find the meson/autotools behavior useful and rely on it. How can you dismiss that by arguing that "they only find it useful because they use meson/autotools". And I'm sure gstreamer has been doing this since before they migrated to meson. |
FYI, every Meson project can do that simply by using |
Although there's a clear MSVC convention of calling import libraries "xxxx.lib", when a build system creates both static and shared libraries, a race condition will be caused [1]. To this end, the Meson build system decided to also apply the GNU convention for the MSVC ABI [2], which is not considered in pkg-config-rs. [1]: https://aomedia-review.googlesource.com/c/aom/+/173603 [2]: mesonbuild/meson#8153
WTF?! pc files also need to work as intended outside of meson. meson is not a closed of ecosystem ..... also we are not speaking about meson & cmake alone there is also qmake/qbs/scons/autotools/b2/bazel/makefiles/perl scripts etc. and the pc file needs to be correct for any build system to come in the future....
Everything is build somehow. You either build from source or install/extract binaries directly into the directories as you want. If it is something which needs to run on the host it is a host dependency. Everything can be provided somehow.
I can be dismissed by the fact that simply because I use x doesn't indicate that x useful or that x even makes sense. If you argue for x due to people using x that is a cyclic argument. Or other way said: You cannot tell why people use x. It might be because there is no similar alternative or they simply dislike y or z even though z is the objectively better or correct solution/answer.
Nope, the MSI installer just shipped MinGW builds (I checked 1.45 and 1.6.4). (considering their dependencies this is no wonder.) So they will probably be fine with any naming reflecting MinGW naming and won't notice the difference to native MSVC naming. But let me apply displayed meson contributor logic here: The existence of this issue proofs that mesons naming convention is flawed on MSVC because otherwise the issue and the discussion around it would simply not exist. |
But isn't what we're doing right now, already the thing that they are fine with? And which they wanted to do, and are doing, and are relying on?
No, it proves that meson's naming convention has reasons for as well as reasons against. The idea of a concept that has both pros and cons isn't novel to computer science or to C++ libraries or even to meson. I have never argued against the idea of a concept that has both pros and cons (though I might feel the cons are misguided, or that there are better solutions). Your standard stock in trade, however, is to argue against the idea of a concept that has both pros and cons. You do this, for example, by protesting that any suggestion of a pro is "circular logic". And when Tristan says "arguing with you has proven to be a waste of time on multiple forums" this is exactly what he's talking about -- the fact that any conversation with you, has a tendency to turn into "meson is not only wrong, but stupid with it, meson should apologize for its insolence and change and drop support for existing OSS workflows that rely on this functionality". Which is apparently the only acceptable outcome, because it "works for vcpkg because we build everything five times after patching the sources to search for prefix-installed versions of any build machine tools" due to "modularity". Needless to say, the idea that build systems should only work pleasantly inside vcpkg is not an attractive idea to me. The fact that meson has real, correct cross compilation support by mixing build and host machines together into a unified single-project configuration in cases where internal, uninstalled intermediate code generators are used, is actually something that quite a few people are very grateful to meson for -- we're not about to revert to cmake levels of hackery because vcpkg thinks it's weird. And it's really not a compelling argument against people wanting to build their project once for release and once for debug and shipping a general purpose release SDK that meets a variety of needs and doesn't involve building large data assets multiple times or shipping multiple copies of them for spurious reasons. |
|
@Neumann-A The problem is pretty simple: The VS default of using Yes that requires some cooperation between build systems. CMake is willing to support Meson's proposal, but seems temporally unable to do that because they admit themself they abuse of PATH (https://gitlab.kitware.com/cmake/cmake/-/issues/24216). Most other build system are pretty terrible with MSVC+pkg-config to begin with. Not sure which one actually has something that works? |
|
@xclaesse: No the problem is meson trying to support a scenario which isn't common to the platform instead of deferring the solution of said problem to the building problem. I fully understand the file/target name problem on windows you don't need to reiterate on it.
Don't assume that both libraries are build by default at the same time on windows. Only allow building one and then use the platform default name. If somebody wants to opt-in to meson multi library type solution feel free to add an option for that. There is no reason why single library type builds should pay a naming fee or why projects should manually set the name.
Ah the blame game. Lets fill in some facts: Meson made the decision to build both types of libraries as such meson could be blamed for the following:
the VS naming existed before meson so meson should have adjusted to it accordingly. Also they are not flawed they are just what they are humanly defined conventions.
They could at least work if the pc file is correct? But no chance if the pc file is already incorrect. However, I again see here the behavior to not own the responsibility for a design decision and just blame somebody else.
Why are we only talking about gstreamer? gstreamer was given as an argument for x behavior in meson for MSVC. However, gstreamer was not directly build with MSVC before? MinGW != MSVC. gstreamer probably simply doesn't know better so it will use the behavior meson dictates and as such the behavior of the current gstreamer MSI Installer cannot be used as an argument to support (or go against) mesons naming.
Yes you can make a list and I would probably argue that the cons are bigger than the pros on Windows, however if you land in the territory of contradictory behavior you should know that something is broken. So where is the contradiction in meson? Ok lets read point 5 in https://mesonbuild.com/FAQ.html#why-does-building-my-project-with-msvc-output-static-libraries-called-libfooa.
I use vcpkg as an example to demonstrate which problem was observed and how it was solved. vcpkg only builds the amount required. OT: How many times does meson build the host part if you target N architectures and want a clean working dir for every architecture? Mixing host(native)/target(cross) builds in one build description is a convenience but simply doesn't scale correctly if you cannot simply reuse the host build. /OT
That is not the target. The target is to make the build system work correctly with windows and deliver correct pc files for consumption. If the build system delivers that then vcpkg will seamless work with it as will probably conan or any other package manager. However, meson does not fulfill this requirement of at least correct pc files for static builds using MSVC. It also doesn't play nice with CMake by default due to the naming decision. (It will work with the automake compile wrapper but not everybody using autotools is also using automake...)
It not hackery. I think CMake made a concise decision to not directly integrate it into the build but defer the solution to the user. The same applies to building both static/shared libraries at the same time. It is simply up to the user to implement if they want/need it. As such CMake doesn't need to solve problems which are unrelated of creating a pure build description for a project. As a side note I personally like Qt6 take on solving cross builds in cmake. So TL;DR
|
|
Note that the discussion has been focused on Meson's usage of libfoo.a static library name, but if I understand correctly @nirbheek here #8153 (comment), you can also build |
|
@xclaesse correct, and gstreamer actually already does this. Our "MSVC" builds are actually building meson projects with MSVC and Autotools projects with MinGW and linking them together. It works fine because everything is using UCRT. We also have Autotools (MinGW) projects picking up and linking to Meson (MSVC) built binaries via pkg-config, and it all works because of Meson's default Windows library naming conventions. For the same reason, we are able to port Autotools projects to Meson and everything continues to work as-is. MSVC and MinGW artifacts are fully compatible. The only difference is that you won't get PDB info from the MinGW artifacts. The same is also done by gvsbuild, IIRC, and MSYS2 has a UCRT64 variant specifically to allow this. |
There is no difference between the MSVC and MinGW C ABIs, so there is no collision either. The only reason there's a difference between naming of MSVC DLLs and MinGW DLLs is because the The only thing to be careful about is that there are different CRTs, and if you mix them, you need to be careful about passing CRT objects across DLL boundaries:
There is no naming convention to differentiate these. Some projects will append So, in practice, it's acceptable to mix MinGW and MSVC artifacts, and GStreamer and GTK (and projects using GStreamer/GTK) and other projects have been doing this for over a decade, before Meson even existed. The convention is to put debug vs release in separate directories. This is already what Visual Studio and Cargo do. When shipping aggregates of artifacts, you should just use separate trees (prefixes). And of course if you're using C++ all this goes out the window, because there is no C++ ABI stability. Any of these can change the ABI:
Library naming cannot do anything here. C++ static libraries are only usable as intermediate formats inside the builddir, and should not be redistributed. |
pkg-config's And this is what the man page says: So the purpose is to avoid outputting flags that the MSVC compiler doesn't understand. It's not meant to be "a flag that you should use to find libraries built with MSVC on Windows". You (and other projects like pkg-config-rs) are misusing it. You should be using the No one should be passing
Does anyone even know why MSVC uses the same name for import libraries and static libraries? I don't think there's a good reason for it at all. Do you know how MSVC solves this naming collision for UCRT? If you want to link to the UCRT dynamically ( Amazing! So even Microsoft knows that this naming collision is problematic, and their solution breaks your so-called "convention". I guess we should petition Microsoft to "fit into the rest of the world" 😉 I am baffled that your "solution" for the file collision is to pretend it doesn't exist. After reading your comments on this issue, I am inclined to agree with @tristan957 that you're too closed-minded to see other people's problems. The core problem here is that there is no "rest of the world" or "convention" around publishing and discovering aggregates of libraries / include directories on Windows. Visual Studio doesn't even provide a way to "install" a package somewhere outside the builddir. Best you can do is to export/import a nupkg, but how do you ship aggregate frameworks that are a combination of libraries from separate FOSS projects? This is something needed by everyone: Qt, GTK, OpenCV, FFmpeg, GStreamer, etc. Conventions around such things are always created by open-source communities, and MinGW was the first community to attempt to make a convention around this on Windows. They, obviously, based their system around what is done in the UNIX world, to make a prefix and put everything in it:
This is the same convention that Meson inherits, and hence we need to solve the filename collision. People who do not need to work in this fashion (proprietary projects) can ignore the filename collision, but that doesn't change the fact that other people care about it. |
|
I think this should close the debate here. It seems that all Meson devs agree that current naming is the best compromise available and that will not be changed. This is also what Autotools does when built with UCRT which is compatible with MSVC, so this is not an issue specific to Meson. Other build systems should adapt to find libraries built with I opened a Meson PR to document the UCRT story as an extra argument for our naming choice: #12163. Closing this issue as I think everything has been said already. Thanks everyone for your input! |
I would be interested in seeing more discussion around this point if other people would find that agreeable because it seems like a good compromise for both positions being argued in this ticket. |
|
@tristan957 even if you don't build both at the same time, you could still install both in the same location. That's what MSYS2 does AFAIK:
With #11981 Meson will be able to build both at the same time (configure once but compile twice automatically). |
|
When compiling with MSVC you can set |
Although there's a clear MSVC convention of calling import libraries "xxxx.lib", when a build system creates both static and shared libraries, a race condition will be caused [1]. To this end, the Meson build system decided to also apply the GNU convention for the MSVC ABI [2], which is not considered in pkg-config-rs. [1]: https://aomedia-review.googlesource.com/c/aom/+/173603 [2]: mesonbuild/meson#8153
Describe the bug
Meson build system currently labels Windows static libraries by default with .a extension in order to distinguish between static and import libs. I understand that Meson supports overriding this behavior with "name_suffix" param.
Shouldn't Meson follow Windows conventions by default?
How does CMake deal with this issue?
Another approach is to use different library names, e.g. lib_xyz.lib and lib_xyz_static.lib or to put the build artifacts in different folders such as static and shared.
Expected behavior
Meson should follow windows convention and name static libs with .lib extension by default.
The text was updated successfully, but these errors were encountered: