JavaBDD和CUDD在64位Windows机器上

huangapple go评论61阅读模式
英文:

JavaBDD and CUDD on a 64bit Windows Machine

问题

我在64位(Windows*)机器上使用CUDD(或BuDDy)后端遇到了一些问题。

我从这里获取了JavaBDD的副本。
它附带了一些后端32位_.dll_-s,但在64位JVM上无用。
因此,我尝试从源代码(镜像)编译CUDD库。

我在Ubuntu WSL上使用mingw-64。

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=...(本地目录)
make
make install

如预期,我在我的_--prefix_目录中找到了_libcudd-3-0-0-0.dll_。
我将dll重命名为_cudd.dll_,因为这是JavaBDD正在寻找的名称,并将其复制到正确的位置(例如,我将运行JAR的目录中)。

当我尝试加载与JavaBDD一起提供的dll时,该库根本无法加载。现在使用新编译的库,它显然可以加载该库(NativeLibraries::findFromPaths(...)返回从预期路径加载的NativeLibrary)。

就在这之后(?在CUDDFactory.registerNatives()时,我无法进入其中,或者在某些未知的静态代码片段期间?)抛出UnsatisfiedLinkageError

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

我希望我提供了足够的细节,以便有人能够解释我的错误并帮助我使其正常运行。如果需要更多细节,请随时提问。

(*我还没有在其他操作系统上尝试过)

英文:

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();

答案1

得分: 1

随机猜测:mingw和Visual Studio之间的符号命名略有不同。在dll上使用dumpbin.exe并搜索registerNatives -
Botje

随机猜测关于原因是错误的,但评论仍然非常有帮助:
快速比较dumpbin /EXPORT的输出,很快就发现与JavaBDD库一起提供的_cudd.dll_与libcudd.dll不是相同来源的。

相反,它是专门的JNI接口实现的编译,与JavaBDD库的源代码一起提供。不幸的是,该项目在代码和构建脚本中都使用了Java 8的不推荐功能,因此需要一些努力才能使其运行。

英文:

> 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.

huangapple
  • 本文由 发表于 2023年6月27日 17:07:34
  • 转载请务必保留本文链接:https://go.coder-hub.com/76563302.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定