JavaBDD and CUDD on a 64bit Windows Machine

Question

I have troubles getting JavaBDD working on a 64bit (Windows*) Machine with the CUDD (or BuDDy) backend.

I obtained a copy of JavaBDD from here.
It shipps with a number of backend 32bit .dll-s, which are useless on a 64bit JVM.
Hence, I tried to compile the CUDD library from the source (mirror).

I used mingw-64 on an Ubuntu WSL.

git clone https://github.com/ivmai/cudd.git .
aclocal
automake
mkdir build
cd build
../configure --enable-shared --enable-dddmp --enable-obj --host=x86_64-w64-mingw32 --build=x86_64-linux-gnu --prefix=... (local directory)
make
make install

As expected, I find the libcudd-3-0-0-0.dll in my --prefix directory.
I rename the dll to cudd.dll, as this is the name, JavaBDD is searching for, and copy it in the right place (e.g. in the directory from which I will run my JAR).

When I was trying to load the dll, that was shipped with JavaBDD, the library could not b loaded at all. Now with the newly compiled library, it apparently loads the lib (NativeLibraries::findFromPaths(...) returns a NativeLibrary, loaded from the expected path).

Right after that (? at CUDDFactory.registerNatives(), in which I could not step into, or during some unknown static code snippets ?) an UnsatisfiedLinkageError is thrown.

UnsatisfiedLinkageError {
   DetailMessage: net/sf/javabdd/CUDDFactory.registerNatives()V
}

I hope I provided enough detail, that someone may shine light on my mistakes and help me, get this running. If more detail is necessary, feel free to ask.

(* I haven't tried it on other OS)

I have already consulted ChatGPT on this matter. It was imaginative, but useless.

---

A small JUnit Test as MVC for the Java Part:

    @Test
    public void registerNativeTest() {
        System.loadLibrary("cudd");
        registerNatives();
    }

    private static native void registerNatives();

Answer 1

Random guess: the symbol naming is slightly different between mingw and visual studio. Use dumpbin.exe on the dll and search for registerNatives – Botje

The random guess was wrong about the reason, but the comment still super helpful: Comparing the output of dumpbin /EXPORT quickly revealed, that the cudd.dll, shipped with the JavaBDD library is not of the same source as libcudd.dll.

Instead it is a compilation of specialised JNI interface implementation, that is shipped with the source code of the JavaBDD library. Unfortunately, the project uses deprecated features of Java 8 in both code an build script, so that it will take some effort to get it running.