Additional link options when using UCRT libraries?

[grimbough]

Thanks for the work in maintaining these packages, they've been really helpful to me. I'm trying to update openssl and libssh2 to debug some issues I'm having with Rhdf5lib under the new ucrt tool chain.

I've successfully built updated versions of both libraries (https://github.com/grimbough/rtools-packages/tree/openssl) and can use them locally. However on my Github action workflow I get linker errors with libcrypto.a reporting undefined reference to sscanf'` (see the "Install dependent packages" section here)

sscanf() seems like its part of the C runtime, and I was wondering if you'd seen this before and whether there was some additional link setting I'm missing. Since it works locally, I guess maybe it's just that my actions runner is configured incorrectly. However I don't run into this issue if I try to use the x64-ucrt libraries you already distribute. With all the various version of R-devel and rtools floating around it's a pretty confusing time in the R for Windows world.

[jeroen]

This linking error typically indicates you have are trying to link a non-ucrt library. I haven't looked closely at your script, but are you sure D:/a/_temp/Library/Rhdf5lib/lib/x64-ucrt/libcrypto.a is really your ucrt64 build, and not the mingw64 one?

With all the various version of R-devel and rtools floating around it's a pretty confusing time in the R for Windows world.

Yes I agree, sadly R-core hasn't discussed any of the new toolchain stuff with me, so there isn't much I can do.

[grimbough]

Thanks for the comments. I checked and I'm pretty sure I'm really using the ucrt64 build in that place. However I built the libraries on a second computer and now have a pipeline that compiles successfully (https://github.com/grimbough/Rhdf5lib/runs/4843467580?check_suite_focus=true)

When comparing the two libcrypto.a files that I've produced, I noticed that there is a difference in their symbol tables with regards to sscanf. The orginal version that fails to link shows:

> nm curl-7.64.1_openssl-1.1.1m_ssh2-1.10.0/x64-ucrt/libcrypto.a | grep scan
                 U sscanf

while the successful version has:

> nm curl-7.64.1_openssl-1.1.1m_ssh2-1.10.0_2/x64-ucrt/libcrypto.a | grep scan
0000000000000f10 t sscanf.constprop.0
                 U __stdio_common_vsscanf

I'm not sure what the difference is between my two MSYS2 setups, both times I just built with the makepkg-mingw instructions from this repo, but I guess I must have done something slightly different. I notice that the second, working, version is also how appears in the libcrypto.a distributed with https://github.com/rwinlib/libcurl