Usually any of the windows related dlls mentioned there are red herrings, they don’t mean much.
But what I can see from the screenshot is that it looks like the jnind4jcpu.dll file is looking for a libopenblas.dll file, but there is only a libopenblas_nolapack.dll file available.
I don’t know if it’s important, but the javacpp logs the following regarding libopenblas_nolapack.dll :
Debug: Loading C:\Users\Tarik.javacpp\cache\openblas-0.3.21-1.5.8-windows-x86_64.jar\org\bytedeco\openblas\windows-x86_64\libopenblas_nolapack.dll
Debug: Loading library openblas_nolapack
Debug: Failed to load for openblas_nolapack@.0: java.lang.UnsatisfiedLinkError: no openblas_nolapack in java.library.path: C:\Program Files\Java\jdk-19\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Program Files\Common Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files\Docker\Docker\resources\bin;C:\Program Files\Git\cmd;C:\Users\Tarik\AppData\Local\Microsoft\WindowsApps;C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2022.3\bin;;C:\Users\Tarik\AppData\Local\GitHubDesktop\bin;.
@partarstu I’ll try to dissect the difference this week. In the mean time the UDF PR should be mergable soon as well.
@agibsonccc , thanks! As soon as UDF PR is merged, I’ll implement my own Op and use it in my graph. But I can’t test it until the issue with javacpp is resolved.
@agibsonccc , so I’ve tried to see what the javacpp logs in M 2.1. Surprisingly all the failures in the logs which are present in the snapshot are as well present in M 2.1. Also in both versions the missing dependency to libopenblas.dll is shown in jnind4jcpu.dll and libnd4jcpu.dll during dependency analysis. But M 2.1 uses javacpp-1.5.7, the snapshot - 1.5.8. Seems like the snapshot has a mismatch of versions / native method signatures. I tried wiping out the whole maven repo and javacpp cache folder, as well as changing the classifier of ND4J backend - the issue persists.
@agibsonccc , I’ve noticed that the PR is merged. When should I expect the build to be run ? I’m interested in windows-x86_64-onednn-avx512
@partarstu I still need to take a closer look at your above issue first. For now I’m focused on debugging one more issue before looking at this. I can technically kick the build for this off now but it won’t d you much good if you’re just running in to the same issue. Otherwise I’d say just go ahead.
@agibsonccc , you’re right - it doesn’t bring me much, but if triggering the build won’t take a lot of time, I could have a code base which would allow me to re-implement my own UDF (I have actually 3 of them) without compilation issues. But if starting getting the build done is a time-consuming part (I saw that the last GitHub Actions builds for windows failed exactly while compiling the javacpp module), I’d rather wait for the main issue to be resolved or the workaround for that issue to be found.
Unfortunately all windows jobs have failed because of libnd4j issues
@agibsonccc , I don’t see native backend for Windows. I’ll try the generic one to see if it works.
Update: got the updated sources which allow me to work further and create my own UDFs. Thanks a a lot ! The windows backend build will be needed after it already has the fix for the main issue included.