On Thursday 27 June 2024 00:35:01 Martin Storsjö wrote:
> On Wed, 26 Jun 2024, Pali Rohár wrote:
>
> > I compiled and linked very simple memcmp() example with mingw-w64
> > runtime and with latest ms runtime (both 32-bit). Tested example is:
> >
> > __declspec(dllimport) int memcmp(const void *a, const void *b, unsigned s);
> > int main(int argc, char *argv[]) { return memcmp(argv[0], "abc", 3); }
> >
> > ms tools created executable which imports memcmp symbol from
> > VCRUNTIME140.dll library. But mingw-w64 imports memcmp symbol from
> > api-ms-win-crt-private-l1-1-0.dll library.
> >
> > I looked at VCRUNTIME140.dll and api-ms-win-crt-private-l1-1-0.dll and
> > seems that both libraries provide similar set of symbols.
> >
> > It is correct that mingw-w54 links with api-ms-win-crt-private-l1-1-0.dll?
> > Should not it do same thing as ms vc, so link with VCRUNTIME140.dll?
> > Meaning that api-ms-win-crt-private-l1-1-0.def would be replaced by
> > vcruntime140.def when creating libucrt.a archive?
>
> No, this aspect is working quite intentionally this way.
>
> The big difference is that api-ms-win-crt-private-l1-1-0.dll is a system
> component, this is available out of the box on modern Windows (as long as
> UCRT is installed/available). Vcruntime140.dll is not a system component,
> but you're supposed to ship it along with your executable. And we don't have
> it - but you'd need to get this binary from MSVC somehow.
>
> Yes, this is a binary where redistribution is allowed, but we prefer to not
> need to ship extra opaque binaries with our executables (where those
> binaries may have extra specifications on how/where you're allowed to
> redistribute them).
Thanks for info! I was looking for other information about this topic
and found some more description in your commit message here:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/0d403d5dd13ce22c07418058f3b640708992890c/
It makes sense. I just see that there is lot of details which are not
documented in one place and it is hard to find correct reasons. If
something is intentional or it is a bug.
> > Note that there is also vcruntime140_app.dll. Where is this used?
>
> Normally, it's not used. But if you redistribute e.g. a WinStore/UWP app,
> which is mostly built/packaged with MSVC, and thus already is shipped with
> vcruntime140_app.dll, then you may want to link against this library. (To do
> this, one probably has to mess with custom spec files for gcc.)
>
> Also note that we provide libucrtapp.a, too. This library is regular UCRT,
> mostly like libucrt.a, but without linking against the private DLL. In this
> case, we instead provide trivial reimplementations (or in the case of
> __C_specific_handler, a stub) of the functions that we normally use from the
> private DLL. (It doesn't contain all functions, but the ones that commonly
> are used.)
I have figured it out from that commit 0d403d5dd13ce22c07418058f3b640708992890c
Anyway, after that commit there are two longjmp implementations which
for ARM seems to be similar.
mingw-w64-crt/misc/longjmp.S
mingw-w64-crt/misc/mingw_longjmp.S
> If you wanted to add a def file for vcruntime140.dll, I guess that's fine,
> but it wouldn't be the common thing to use. If a user would link with
> -lvcruntime140 -lucrt, then it should prefer picking functions from
> vcruntime140 and probably not link anything from the private DLL either.
>
> // Martin
I see. I just did not understood why the behavior is different and
keyword "private" in the DLL name which mingw-w64 runtime emitted
sounded for me as an issue.
I think that linking with vcruntime140 should work without modifying
spec files. Just calling gcc source.c -lvcruntime140 should work as the
libucrt.a is appended by gcc at the end, and symbols from first lib
should take precedence over symbols from second lib. But mingw-w64 does
not have libvcruntime140.a import library to do easy test of this my
assumption.
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
