在 2019/11/11 22:11, Kacvinsky, Tom 写道: > AS you know, I had to build a custom GCC toolchain with UCRT support in the > MinGW-w64. > > What I did next (aside from building our product) is build Microsoft's Z3 > theorem prover > software. > > Here is the weird thing: > > On my machine, both Z3 built with the custom MinGW-w64 toolchain and Visual > Studio 2017 > work fine wit the UCRT installed on my machine (Windows 10), but on our > automation test > machines (Windows 7), there is an issue loading the libz3 DLL. The error is > that the UCRT DLL > api-ms-win-crt-runtime-l1-1-0.dll fails to load as it needs the entry > calloc(). >
First, please use the following command to print all exported/imported functions from/by `libapi-ms-win-crt-runtime-l1-1-0.a`: nm libapi-ms-win-crt-runtime-l1-1-0.a | grep -F calloc As this .A file should have been generated from a .DEF file, it doesn't reference `calloc()` directly, so there should be no output. > This is odd in the sense that from what I can see, the UCRT library > referended above doesn't > have a dependency on api-ms-win-crt-heap-l1-1-0.dll, in which calloc is > defined and exported. > > Any ideas on the next diagnostic steps. I find it strange that Visual Studio > built Z3 works on > both classes of machines, but the MinGW-w64 built Z3 doesn't. It makes me > wonder if there > is an issue with how the MinGW-w64 CRT (UCRT based) is generating the lib > files used for > linking, so we have entry point errors. > > Then, you may wish to use LDD or Dependency Walker to find out whether `api-ms-win-crt-heap-l1-1-0.dll` references any further DLLs. Sometimes a DLL may fail to load due to lack of a symbol that is requested indirectly, not the failed DLL itself. -- Best regards, LH_Mouse
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
