Python4j can't find dependent libraries

Ok then do you mind just asking me for clarification if you don’t understand something I give you? I’m happy to do that and it’s much easier here.

I mentioned that because sometimes other python installs exist on people’s computers usually in the windows PATH which the native loader will pick up and use by default. This causes problems.

The only way to really know is to just use dependencies and see. I’m hoping by providing hints to particular problems you’ll know what to look for.

Options :
-h -help : display this help
-json : activate json output.
-cache : load and use binary cache in order to prevent dll file locking.
-depth : limit recursion depth when analysing loaded modules or dependency chain. Default value is infinite.
-apisets : dump the system’s ApiSet schema (api set dll → host dll)
-apisetsdll : dump the ApiSet schema from apisetschema (api set dll → host dll)
-knowndll : dump all the system’s known dlls (x86 and x64)
-manifest : dump embedded manifest, if it exists.
-sxsentries : dump all of 's sxs dependencies.
-imports : dump imports
-exports : dump exports
-modules : dump resolved modules
-chain : dump whole dependency chain

Which option to use?

There should be a GUI for you to use. Look fro DependenciesGUI.exe

This is for M1.1

This is for M2

Both M1.1 and M2 have the same root cause:
jnipython.dll: Can’t find dependent libraries

@SidneyLann Could you run the GUI on this as well?
C:\Users\Administrator.javacpp\cache\cpython-3.10.2-1.5.7-windows-x86_64.jar\org\bytedeco\cpython\windows-x86_64\python310.dll

Debug: Loading /home/sidney/.javacpp/cache/pcng-idea-ner-1.0-bin.jar/org/bytedeco/cpython/linux-x86_64/libpython3.10.so.1.0
Debug: Loading /home/sidney/.javacpp/cache/pcng-idea-ner-1.0-bin.jar/org/bytedeco/cpython/linux-x86_64/libjnipython.so
Debug: Loading class org.bytedeco.javacpp.presets.javacpp
Debug: Loading class org.bytedeco.cpython.global.python
Debug: Loading class org.bytedeco.cpython.PyThreadState
[main] INFO org.nd4j.python4j.PythonGIL - Pre Gil State ensure for thread 1
[main] INFO org.nd4j.python4j.PythonGIL - Thread 1 acquired GIL
Debug: Loading class org.bytedeco.javacpp.presets.javacpp
Debug: Loading class org.bytedeco.cpython.global.python
Debug: Loading class org.bytedeco.cpython.PyObject
Debug: Loading class org.bytedeco.javacpp.presets.javacpp
Debug: Loading class org.bytedeco.javacpp.BytePointer
Hello World
[main] INFO org.nd4j.python4j.PythonGIL - Releasing GIL on thread 1

Run on centos8 successfully. This is enough for me! Thanks.

@SidneyLann thanks for flagging on windows though. There does indeed appear to be a missing library there if you look at it. Are you running on windows 10 or 11?

I’m running on win7.

It looks like CPython wants to link with api-ms-win-core-path-l1-1-0.dll which is only available from Windows 8, so it probably won’t run on Windows 7. If you need this to work on Windows 7, you can try to build from source:

Thanks. The linux version is ok for me.

miniconda can only be download for py <=3.9 now, why not use py 3.9 in M2? usually the biggest main version of py is not stable.

We can of course support older versions of CPython, and contributions are welcome:

@SidneyLann piling on to Sam a bit if you want x additional support for a feature that costs us time.
Supporting the most recent version works for most people. Users don’t care enough to give time or money to additional support for features like that.

The only thing that aligns for us as a project to give time out is to increase the marketshare of the frameworks/tools we build for internal use cases while maximizing the benefit for the most people possible.

Where that tends to be good for the maintainers of a project and the most users is just supporting the most recent version of something.

Regarding conda, you can use M1.1 python4j and it should work fine.
You can also find newer versions of conda here:

I much more prefer this one over the official one. The anaconda version on the home page is actually broke for ARM processors but worked fine here. So I trust this more over the binaries on the home page.

Thanks. I am rebuiding tf to use M2 and py 3.10.2.