On Thu, 27 Jun 2024, Pali Rohár wrote:
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.
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.
Yes - in principle, I guess there's no formal guarantee that the private
DLL won't change and break these functions we rely on from there. But in
practice, it's unlikely.
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.
If linking with LLD, then yes, this is enough. If linking with ld.bfd,
unfortunately, things are more complicated.
With ld.bfd, it searches libraries only literally in the order they are
specified. If the linker is called with e.g. "myapp.o -lvcruntime140
-lmingwex -lucrt", then object files from libmingwex won't search in
libvcruntime140.a at all, it will only look in -lucrt and following
libraries. That's why the default linking options contains many repeated
-lmsvcrt -lkernel32 and such.
Therefore, with ld.bfd, to make sure vcruntime140 takes precedence over
UCRT, you need to pass a separate -lvcruntime140 before every single
invocation of -lmsvcrt/-lucrt in the linker command line - which
essentially requires using a custom spec file.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
