Krótko mówiąc: mam wykonywalny jar, który dzwonijni.dll który jest zależny odlib.dll. A ja się bojęUnsatisfiedLinkError.

To odpowiedź jest dość bliska, ale z mojego doświadczenia nie rozwiązuje problemu. Nawet gdy folder, w którym znajduje się dll, jest określony wjava.library.path, to nie zadziała. Muszę zmienić WindowsPATH zmienna środowiskowa. W rzeczywistości domyślniejava.library.path w systemie Windows wydaje sięPATH.

Czy jest jakiś „ładny” sposób, aby to naprawić? Chcę zbudować instalator dla systemu Windows i zastanawiam się, jak poradziłbym sobie z tym problemem, aby użytkownik końcowy nie musiał wykonywać żadnej pracy ręcznej.

EDYTOWAĆ:

To, co zaimplementowałem, jest następujące: aplikacja jest dostarczana z folderem o nazwie „native_libs”, który ma dynamiczne biblioteki dla wszystkich obsługiwanych architektur. Struktura jest następująca:

/
+- native_libs/
   +- windows/
   |  +- x86/
   |  |  +- ...
   |  +- x64/
   |     +- ...
   |
   +- linux/
   |  +- x86/
   |  |  +- ...
   |  +- x64/
   |     +- ...
   |
   +- libs/
      +- ...

W czasie wykonywania, podczas inicjowania aplikacji, wykrywana jest poprawna architektura JRE i system operacyjny, a odpowiednie pliki biblioteki są kopiowane do folderu libs /. Thejava.library.path jest również ustawiany w czasie wykonywania za pomocą wspólnego hakowania. WreszciePATH zmienna środowiskowa dla okien jest ustawiana za pomocą rodzimego programu uruchamiającego.

Jakieś pole do poprawy? Może kopiowanie biblioteki dll w tym samym katalogu cojar plik negowałby potrzebę ustawianiajava.library.path iPATH zmienne? Muszę zbadać ładowanie biblioteki DLLSystem.load() jak również, że nie będzie potrzeby kopiowania plików.