Graal: What .dlls are needed for a Windows binary?

[borkdude]

If I'm compiling a binary on Windows 10 with GraalVM native, what .dlls are needed on other Windows 10 systems to be able to run this binary?

Does the --static option have any effect on this?

In installing Visual Studio C++ 2010 redistributable sufficient? After some testing it seems so.

Also, if there are any open source projects already building Windows binaries for distribution, I'd be happy to take a peek!

We have been able to compile a Windows binary on Appveyor, but it doesn't work on Windows 10 systems:
https://github.com/borkdude/clj-kondo/blob/master/appveyor.yml

[olpaw]

Does the --static option have any effect on this?

It doesn't. See https://github.com/oracle/graal/blob/9ce4ed93a2797e922ff3a364e1f7b192984b9537/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/image/NativeBootImageViaCC.java#L161win

In installing Visual Studio C++ 2010 redistributable sufficient?

Generally, yes. (E.g. zlib is not needed on Windows as it is included in jre\lib\zip.lib in graalvm-19.0.2 on Windows). If you need native-code security providers the same rules as on other platforms apply. (see https://github.com/oracle/graal/blob/master/substratevm/JCA-SECURITY-SERVICES.md). On Windows the dll is in jre\bin\sunec.dll.

cc @pejovica @cstancu

[sogaiu]

For Windows 10, msvcr100.dll from VS C++ Redistributable 2010 appears to be sufficient for simple setups.

On a related note, due to Windows' different and complicated methods of determining which dlls to load, it appears significantly more complex than necessary (at least compared to macos and various linux distributions) to ensure the appropriate dll is loaded and not some other file that happens to have the same name.

Some details of these issues are touched upon here:

https://github.com/numpy/numpy/wiki/windows-dll-notes

After various false starts, I had some success with getting a side-by-side private assembly to work, which IIUC can ensure (or at least drastically increase the chance) that the specific dlls one wishes to have used by the executable to actually be used (instead of "already loaded" by the system ones, for example).

In the current situation though, to follow this approach, IIUC, we must provide an external application manifest as well as an external assembly manifest, and this process appears to have some undocumented gotchas:

http://csi-windows.com/blog/all/27-csi-news-general/245-find-out-why-your-external-manifest-is-being-ignored

From the perspective of debugging, deployment, and security, it would be nice to have the static compilation option.

[remkop]

Are there any plans to include msvcr100.dll in the generated native image? I verified that with 19.2.1 this dll is still required as an external dependency to be able to execute the native image.