java.lang.UnsatisfiedLinkError - Проблема с собственным методом

1

У меня возникла проблема в Java (Eclipse) относительно использования DLL. До сих пор у меня возникает следующая проблема:

Uncaught Exception for agent SomeAgent 
java.lang.UnsatisfiedLinkError: SomePackage.SomeClass.SomeNativeMethod(II)Z
[...]
at jade.core.behaviours.Behaviour.actionWrapper(Behaviour.java:344)
at jade.core.Agent$ActiveLifeCycle.execute(Agent.java:1532)
at jade.core.Agent.run(Agent.java:1471)
at java.lang.Thread.run(Thread.java:745)

Я не знаю, поможет ли это выяснить проблему, но я также использую JADE в этом проекте...

EDIT (28/04/2014):

DLL, которую я пытаюсь использовать, является обычным (была создана бывшим сотрудником из компании, где я работаю).

Любопытная вещь об этой проблеме заключается в том, что у меня есть два проекта java, которые выполняют аналогичные задачи. Один из этих проектов отлично работает, а другой - UnsatisfiedLinkError.

О путях: я создал определенную папку для библиотек DLL, которая содержится в папке рабочего пространства, но не внутри папки проекта (другими словами, в той же папке, где находятся bin, src, bibs, settings и т.д.). Конфигурация этой папки одинакова для обоих проектов, которые у меня есть. Кроме того, я уже протестировал метод System.out.println(System.getProperty("java.library.path") и верный путь возвращается в обоих случаях.

EDIT (29/04/2014):

Просто добавлена дополнительная информация об ошибках. Я начинаю думать, что проблема может быть связана с использованием JADE...

  • 0
    Этот тип ошибки обычно вызывается библиотеками в вашей программе.
  • 0
    Это нестандартная DLL или стандартная? Находится ли DLL в вашем пути к библиотеке? Вы добавили библиотеку в Eclipse? i.imgur.com/wl2vAu6.png
Показать ещё 2 комментария
Теги:
dll
jni
agents-jade

4 ответа

1

Вот процедура PD, которая может помочь вам идентифицировать проблему.

Добавьте в свою программу следующую информацию, чтобы определить различия в пути арки и загрузки между двумя средами среды выполнения. Исследуйте любые различия в пути/арке.

 System.out.println(System.getProperty("java.library.path"));
 System.out.println(System.getProperty("sun.arch.data.model"));

Вы можете использовать утилиту dumpbin.exe для определения зависимостей, необходимых для загружаемой DLL. Убедитесь, что существуют зависимости. Пример использования:

C:> dumpbin /imports your.dll 

Dump of file your.dll
File Type: DLL
  Section contains the following imports:
    **KERNEL32.dll**

Вы можете использовать команду where.exe, чтобы найти местоположение зависимостей. Пример использования:

C:>where KERNEL32.dll
    C:\Windows\System32\kernel32.dll

Если ты видишь:

C:>where KERNEL32.dll
    INFO: Could not find files for the given pattern(s)

Изучите, почему зависимая DLL не находится на пути.

Вы можете использовать команду dumpbin.exe для проверки 64-битного и 32-битного.
Пример:

C:>dumpbin /headers yourd.dll

 Dump of file yourd.dll
 PE signature found
 File Type: DLL
 FILE HEADER VALUES
         14C machine (x86)    <-- 32bit DLL

C:>dumpbin /headers yourd.dll

 Dump of file yourd.dll
 PE signature found
 File Type: DLL
 FILE HEADER VALUES
         8664 machine (x64)    <-- 64bit DLL

Исследуйте любые 32-разрядные и 64-разрядные несоответствия между основными/зависимыми. Если ваша JVM 32-битная, вам нужно использовать 32-битные DLL файлы. Если ваша JVM составляет 64 бит, вам необходимо использовать 64-битные DLL файлы. (Это нормально для запуска 32-битной JVM на 64-битной ОС, но JNI DLL должны быть 32 бит (DLL соответствуют JVM, а не ОС).

Поделиться
  • 0
    Ну, я проверил все, что вы рекомендовали, и, похоже, нет проблем с совместимостью битов. Тем не менее, я только что заметил, что были некоторые сообщения об ошибках, которые связаны с нефритом (см. Мое сегодняшнее издание). Может быть, проблема может быть связана с несовместимостью между нефритом и окружающей средой?
0

В отличие от нескольких ответов здесь, это не проблема загрузки библиотеки. См. Трассировку стека. Это проблема поиска метода, названного в исключении. Это вызвано несоответствием между фактическими и ожидаемыми именами. Популярные причины:

  • не использовать javah для создания файла.h
  • подпись метода в файлах.h и.c/.cpp не согласна
  • не включая файл.h в файле.c или.cpp
  • изменение пакета или имени класса Java после запуска javah
  • изменение имени метода или подписи после запуска javah

Если вы выполните одно из двух последних, вы должны повторно запустить javah и настроить файл.c/.cpp, чтобы согласиться с новой сигнатурой в новом файле.h.

Поделиться
0

Это может быть связано с несоответствием версии или несоответствием бит вашей библиотеки. Вы можете работать с 64-разрядной ОС, использовать 64-разрядные версии ваших JAR файлов. Также проверьте несоответствие версий между JARS.

Поделиться
-2

Когда вы используете некоторую собственную библиотеку, ваша система проверит ее как в переменной среды, так и в java.library.path. системного свойства, если он не найден там, тогда он будет вызывать java.lang.UnsatisfiedLinkError. Windows pick dll формирует system32, потому что папка system32 уже существует в пути, так что с этой стороны происходит очень мало изменений формы ошибки. Нативные библиотеки делают платформу java-кода зависимой. Проверьте свой java-путь для необходимой DLL. Проверьте свой java.library.path и попробуйте загрузить свою библиотеку (без расширения dll) с помощью System.loadLibrary("имя библиотеки"). Надеюсь, это поможет. :)

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню