2016-09-13 1 views
1

J'essaie d'exécuter une application HelloWord Java qui accède au client Notes sur un Mac. Je l'avais travaillé sur des versions plus anciennes. Actuellement, j'ai Java 1.8.0_101-b13 un OS/X 10.11.6. Je tente d'exécuter ce code:Exécution d'une application Java IBM Notes sur OS X El Capitan throws UnsatisfiedLinkError

import lotus.domino.NotesException; 
import lotus.domino.NotesFactory; 
import lotus.domino.NotesThread; 
import lotus.domino.Session; 

public class HelloWorld { 

    public static void main(String[] args) throws NotesException { 
    HelloWorld hw = new HelloWorld(); 
    hw.sayHello(); 
    } 

    private void sayHello() throws NotesException { 
    System.out.println("java.library.path: "+ System.getProperty("java.library.path")); 
    System.out.println("PATH: "+ System.getenv("PATH")); 
    NotesThread.sinitThread(); 
    Session s = NotesFactory.createSession(); 
    System.out.println(s.getEffectiveUserName()); 
    NotesThread.stermThread(); 
    } 
} 

J'ai mis LD_LIBRARY_PATH=/Applications/IBM Notes.app dans une configuration d'exécution Eclipse. Lorsque je lance l'application, j'obtiens:

java.library.path: /Applications/IBM Notes.app:/Users/joe/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:. PATH: /Applications/IBM Notes.app:/usr/bin:/bin:/usr/sbin:/sbin Exception in thread "main" java.lang.UnsatisfiedLinkError: no lsxbe in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at lotus.domino.NotesThread.load(Unknown Source) at lotus.domino.NotesThread.checkLoaded(Unknown Source) at lotus.domino.NotesThread.sinitThread(Unknown Source) at com.notessensei.HelloWorld.sayHello(HelloWorld.java:31) at com.notessensei.HelloWorld.main(HelloWorld.java:20)

Le chemin de la bibliothèque semble OK. Je dois manquer quelque chose d'évident?

Mise à jour: Quand vous regardez la sortie, Java prend la variable LD_LIBRARY_PATH, donc DYLD_LIBRARY_PATH ne semble pas être nécessaire (je l'ai ajouté à tester en vain). DYLD ... semble be problematic sur OS/X. Une pensée qui n'est pas claire: Dans le monde OS/X, vous pointez généralement vers l'App (IBM Notes.app), mais le contenu est en réalité dans appname.app/Contents/MacOS. Je pense que j'ai essayé les deux avec le même résultat. Est-ce que l'espace dans le chemin vomit?

Mise à jour 2: Comme l'a demandé la sortie de otool -L liblsxbe.dylib

liblsxbe.dylib: @executable_path/liblsxbe.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libxmlproc.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libnotes.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

otool -L libxmlproc.dylib

libxmlproc.dylib: @executable_path/libxmlproc.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libnotes.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

`otool -L libnotes.dylib »

libnotes.dylib: @executable_path/libnotes.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0) @executable_path/libjsmac.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libndgts.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libxmlproc.dylib (compatibility version 0.0.0, current version 0.0.0) @executable_path/libgsk8iccs.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55471.14.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 20.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 157.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.14.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.19.0) /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 673.2.1) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 59.0.0)

Quoi d'autre?

+0

C'est «DYLD_LIBRARY_PATH» sur Mac OS X – user2543253

+0

@ user2543253 plus: https://github.com/soumith/cudnn.torch/issues/111 bloqué sur El Captain. Et j'ai mis cela aussi - en modifiant la question – stwissel

+0

Ah, bon à savoir, merci. Mais la bibliothèque est-elle réellement dans '/ Applications/IBM Notes.app'? Je m'attendrais plutôt à '/ Applications/IBM Notes.app/Contents/MacOSX' – user2543253

Répondre

0

Après beaucoup de sondage, il s'est avéré qu'il y avait 2 problèmes à résoudre. Le premier est décrit dans un post by Mikkel Flint Heisterberg. En plus de DYLD_LIBRARY_PATH, une autre variable d'environnement doit être définie: NOTESBIN. Les deux pointent au même emplacement:

DYLD_LIBRARY_PATH=/Applications/IBM Notes.app/Contents/MacOS 
NOTESBIN=/Applications/IBM Notes.app/Contents/MacOS 

Aucune citation ou barre oblique inverse n'est requise dans la configuration d'exécution Eclipse.

La seconde était plus délicate. Par commodité, puisque cela fonctionnait avant, j'avais créé une nouvelle entrée "installé JVM" appelée "Notes9". Là je ai pointé à l'Oracle JVM8 (oui, sur Mac Notes est en cours d'exécution Java8) et Notes.jar (et les autres) dans jvm/lib/ext du répertoire du programme Notes.

Mac n'aime plus ça. Une fois que j'ai pointé vers une JVM8 "nue" et ajouté Notes.jar en tant que dépendance Jar externe, tout a commencé à fonctionner comme prévu.