JNI C ++ DLL - 'UnsatisfiedLinkError：％1不是有效的Win32应用程序' [英] JNI C++ DLL - 'UnsatisfiedLinkError: %1 is not a valid Win32 application'
问题描述
在尝试使用我的实际代码之前，我试图让JNI正常工作，但是在我从C ++编译DLL并运行我的Java应用程序后，我得到：
I am trying to actually get JNI working before I dive in with my actual code, but after I compile a DLL from C++ and run my Java application I get:
Exception in thread "main" java.lang.UnsatisfiedLinkError: <snip>\workspace\JNI test\native\jnitest.dll: %1 is not a valid Win32 application
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(Unknown Source)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at net.condorcraft110.jnitest.JNITest.main(JNITest.java:11)
Google搜索这一点，我知道这通常是由于尝试使用32位JVM加载64位DLL引起的。但是，我的JVM是64位，由 sun.arch.data.model 等于64证明。
Having Googled this for a bit, I know that this is usually caused by trying to load a 64 bit DLL with a 32 bit JVM. However, my JVM is 64 bit, as evidenced by sun.arch.data.model equalling 64.
我的makefile：
My makefile:
CLASSPATH = ../bin
vpath %.class $(CLASSPATH)
all : jnitest.dll
jnitest.dll : jnitest.o
g++ -m64 -Wl,--add-stdcall-alias -shared -o $@ $<
jnitest.o : jnitest.cpp jnitest.h
g++ -m64 -I"C:\Program Files\Java\jdk1.7.0_51\include" -I"C:\Program Files\Java\jdk1.7.0_51\include\win32" -c $< -o $@
jnitest.h : net/condorcraft110/jnitest/JNITest.class
javah -verbose -classpath $(CLASSPATH) -o jnitest.h net.condorcraft110.jnitest.JNITest
clean :
rm jnitest.h jnitest.o jnitest.dll
JNITest.java：
JNITest.java:
package net.condorcraft110.jnitest;
public class JNITest
{
private static native void test();
public static void main(String[] args)
{
System.out.println("sun.arch.data.model = " + System.getProperty("sun.arch.data.model"));
System.loadLibrary("jnitest");
test();
}
}
jnitest.h由javah生成：
jnitest.h as generated by javah:
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class net_condorcraft110_jnitest_JNITest */
#ifndef _Included_net_condorcraft110_jnitest_JNITest
#define _Included_net_condorcraft110_jnitest_JNITest
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: net_condorcraft110_jnitest_JNITest
* Method: loadPlugins
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_net_condorcraft110_jnitest_JNITest_test
(JNIEnv *, jclass);
#ifdef __cplusplus
}
#endif
#endif
jnitest.cpp：
jnitest.cpp:
using namespace std;
#include <jni.h>
#include <iostream>
#include "jnitest.h"
extern "C" JNIEXPORT void JNICALL Java_net_condorcraft110_jnitest_JNITest_test(JNIEnv *env, jclass clazz)
{
cout << "jni test successful" << endl;
}
任何人都知道为什么这不起作用？
Anyone know why this isn't working?
编辑： java.library.path 绝对指向 native ，在Eclipse运行配置中设置。
编辑2：如果我使用VS2013编译它，则DLL可以工作，但我真的不要如果我能帮忙的话，我想把我的项目绑定到Visual Studio。
java.library.path definitely points to native, as set up in an Eclipse run configuration.
Edit 2: the DLL works if I compile it with VS2013, but I really don't want to tie my project to Visual Studio if I can help it.
推荐答案
对我来说，问题是我的新问题-added DLL依赖于我不知道的其他DLL。 Windows有帮助地走了，在我的路径中发现了一个32位版本，但无法加载它，因为我的应用程序是64位。
For me, the problem was that my newly-added DLL relied on other DLLs I didn't know about. Windows helpfully went out and found a 32-bit version in my path, but was unable to load it, as my application is 64-bit.
我用 Dependency Walker （有32位和64位版本，以及Itanium ......）和进程监视器来调试它。它的长短是确保你的DLL插入的每一个DLL也是64位，你会更开心。
I used Dependency Walker (there are 32 and 64-bit versions, as well as Itanium...) and Process Monitor to debug this. The long and short of it is make sure that every single DLL that your DLL pulls in is also 64-bit, and you'll be a lot happier.
有一点要注意的是，如果Windows找到一个正确名称的32位DLL，它将尝试加载它，而在Process Monitor中，它看起来就像是在成功读取它。确保继续向下滚动!!您可能会发现系统丢弃此DLL并继续搜索64位版本的路径。
One thing to watch out for is if Windows finds a 32-bit DLL of the right name it will try to load it, and in Process Monitor it will look like it's reading it successfully. Make sure to keep scrolling down!! You may find that the system discards this DLL and moves on to keep searching the path for a 64-bit version.
更新：
另外两件事需要注意：
Update:
Two other things to be aware of:
1）Old Dependency Walker看起来像它加载的DLL不匹配，例如它可能首先找到一个32位匹配，当你真的想要一个64位DLL，并告诉你有CPU类型不匹配。刚刚获得新版本，这个问题就消失了。感谢 https://stackoverflow.com/a/22384936/309502 获取此信息。
1) Old Dependency Walker can look like there are mismatches for the DLLs it loads e.g. it might find a 32-bit match first, when you really wanted a 64-bit DLL, and tell you there are CPU type mismatches. Just get the new version, and this issue goes away. Thanks to https://stackoverflow.com/a/22384936/309502 for this information.
2）当你加载DLL时，顺序很重要。我没有意识到我正在以错误的顺序装载其中两个，并且无法弄清楚它为什么不起作用。检查您是否先加载先决条件。 ： - ）
2) Order matters when you're loading DLLs. I didn't realize I was loading two of them in the wrong order and could not figure out why it wasn't working. Check that you load the prerequisites first. :-)
这篇关于JNI C ++ DLL - 'UnsatisfiedLinkError：％1不是有效的Win32应用程序'的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
