2013-11-01 3 views
1

У меня проблема с JNI, опять же ...Проблемы JNI с файлами dll

На этот раз мой код работает ... Но ... не правильный на всех ПК.

У меня есть: файл

  1. Jar -> моя прога
  2. DLL файл -> с собственными методами
  3. другой файл DLL -> с другой функции.

На моем компьютере все эти файлы находятся в одной папке.

Файлы код (.java):

// loading library 
    try { 
     Runtime.getRuntime().loadLibrary("E140tests"); 
     setText("Library E140tests.dll was loaded correctly."); 
    } catch (UnsatisfiedLinkError ex) { 
     // try load with absolute path 
     setText("Error: E140tests.dll wasn't loaded!"); 
     setErrorFlag(true); 
    } 

E140tests.dll -> второй файл (compileted в МСВС)

#include "jni.h" 
#include "jni_md.h" 
#include "Lusbapi.h" 
#include "LusbapiTypes.h" 
#include "JNITEST2.h" 

#ifdef __cplusplus 
extern "C" { 
#endif 

/* 
* Class:  JNITEST2 
* Method: ADCinit 
* Signature: (LJNITEST2;)V 
*/ 
JNIEXPORT void JNICALL Java_JNITEST2_ADCinit 
    (JNIEnv* env, jobject, jobject obj) { 
    ... 

lusbapi.dll -> третий файл, с другой функции.

#ifndef __LusbapiH__ 
#define __LusbapiH__ 

// -------------------------------------------------------------------------- 
// ---------------------------- COMMON PART --------------------------------- 
// -------------------------------------------------------------------------- 
#include <windows.h> 
#include "LusbapiTypes.h" 

Если я бросаю свои файлы в system32, все работает тоже.

Но. На другом ПК (xp, 7) мой код не работает! Не имеет значения: если файлы (+ dll) находятся в одной папке или файлы dll находятся в system32 -> код не может их найти.

Я думал, что проблема в Runtime Libraries (MSVS), но Венна я их, ничего не изменилось ...

(на моем компьютере являются IntelijIDEA, МСВС, jdk7.xx -> все работает. Я тестировал прог на другом ПК (с установленным MSVS) -> и все работало, но на другом -> dll не было найдено (и с установленными Runtime Libraries)).

я буду ждать помощи)

+1

Вы пытались изучить зависимости с помощью [Dependency Walker] (http://www.dependencywalker.com)? – dnk

+0

'Ошибка: по крайней мере одна требуемая неявная или перенаправленная зависимость не найдена. Ошибка: были найдены модули с разными типами процессоров. 'На компьютере не работает ... –

+0

Какова архитектура системы, которая не работает, и архитектура системы, которая используется для компиляции? –

ответ

1

К сожалению, при компиляции .DLL, она совместима только с системами согласования архитектуры.

aka: 32-разрядная работа .DLL на 32-битных машинах, то же самое касается 64-разрядных. Есть тактика, чтобы обойти это (покупка лицензии на визуальную студию дает вам инструменты, которые позволят это, и будет создавать специфичные для платформы DLL), но это означает, что вам нужно связать соответствующий .DLL с любой версией программы, которую вы повторное тестирование. Именно поэтому на сайтах он спрашивает, есть ли у вас 32-разрядная или 64-разрядная машина большую часть времени.

Это также одна из основных причин, по которой Java является приятным, потому что это «независимая от платформы» (я использую этот термин свободно, поскольку другие вещи могут влиять на это, чтобы сделать его неверным).

В любом случае, как только вы добавляете вызовы JNI, вы добавляете целую совокупность зависимостей, которые затрудняют распространение программного обеспечения.

+0

Я не уверен. У моего друга есть система x64, и все работает правильно! .. , но на другом ПК (с x64) -> не –

+0

, если это так, то, скорее всего, случайность, что это срабатывает на его, а не на другом. Вообще говоря, DLL определенно зависит от платформы, было бы трудно точно определить разницу между двумя платформами, если бы я не знал точные спецификации обеих систем, и даже тогда содержимое .Dll могло бы изменить ситуацию. – WillBD

+1

@AndrewEvt Если это сработало на 64-битной машине вашего друга, он должен был установить 32-разрядную Java. –

0

Вы должны скомпилировать DLL в обеих архитектурах. Для компиляции вы можете использовать свою 64-битную систему и использовать эти команды для компиляции.

Для 64 бита (GCC)

gcc -o E140Tests64.dll -shared -IC:\....\include sourcefile.c 

для 32 бита (GCC)

gcc -o E140Tests.dll -shared -IC:\....\include sourcefile.c 

Надежда это помогает.

0

Если вы собираетесь распространять свое приложение, вам нужно будет создать 32-битную и 64-разрядную версии вашей DLL. Затем используйте следующую технику, чтобы загрузить надлежащую DLL независимо от вашей JVM-архитектуры ваших клиентов. Добавьте в созданный выходной файл 32 или 64 (MyJniDLL32.dll & MyJniDLL64.dll).

String archDataModel = System.getProperty("sun.arch.data.model"); 
System.loadLibrary(libraryName+archDataModel); 

Свод DLL (32 против 64), должны совпадать с JVM ACH (32 против 64), а не OS арки. Если вы используете 32-битную JVM на 64-битной ОС, ваш код Java должен иметь доступ к 32-битной DLL.

Смежные вопросы