Temurin-build: LinkError auf GUI-Apps unter MacOS

Erstellt am 10. Sept. 2018  ·  26Kommentare  ·  Quelle: adoptium/temurin-build

_Von @helenmasters am 5. September 2017 13: 7_

Unter OSX tritt ein Problem auf, wenn wir versuchen, GUI-Anwendungen auszuführen. Es sieht so aus, als ob / Users / jenkins / workspace fest codiert ist und daher nicht auf dem Computer des Benutzers aufgelöst werden kann.

Exception in thread "main" java.lang.UnsatisfiedLinkError: /Users/helenmasters/sdks/check/jdk8u144-b01/jre/lib/libfontmanager.dylib: dlopen(/Users/helenmasters/sdks/check/jdk8u144-b01/jre/lib/libfontmanager.dylib, 1): Library not loaded: /Users/jenkins/workspace/openjdk_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib
  Referenced from: /Users/helenmasters/sdks/check/jdk8u144-b01/jre/lib/libfontmanager.dylib
  Reason: image not found
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:93)
    at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:80)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.lwawt.macosx.LWCToolkit.<clinit>(LWCToolkit.java:79)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at java.awt.Toolkit$2.run(Toolkit.java:860)
    at java.awt.Toolkit$2.run(Toolkit.java:855)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)
    at javax.swing.UIManager.getSystemLookAndFeelClassName(UIManager.java:611)
    at javax.swing.UIManager$1.run(UIManager.java:1233)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.swing.UIManager.loadSwingProperties(UIManager.java:1228)
    at javax.swing.UIManager.initialize(UIManager.java:1457)
    at javax.swing.UIManager.maybeInitialize(UIManager.java:1426)
    at javax.swing.UIManager.getUI(UIManager.java:1006)
    at javax.swing.JPanel.updateUI(JPanel.java:126)
    at javax.swing.JPanel.<init>(JPanel.java:86)
    at javax.swing.JPanel.<init>(JPanel.java:109)
    at javax.swing.JPanel.<init>(JPanel.java:117)
    at citmsxa.<init>(citmsxa.java:11)
    at citmsxa.main(citmsxa.java:376)

Hier ist die Ausgabe des Befehls otool, die darauf hinweist, dass der Pfad falsch ist ...

helens-mbp:check helenmasters$ otool -L /Users/helenmasters/sdks/check/jdk8u144-b01/jre/lib/libfontmanager.dylib
/Users/helenmasters/sdks/check/jdk8u144-b01/jre/lib/libfontmanager.dylib:
    @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0)
    /Users/jenkins/workspace/openjdk_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib (compatibility version 12.0.0, current version 12.0.0)
    @rpath/libawt.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
    @rpath/libjava.dylib (compatibility version 1.0.0, current version 1.0.0)
    @rpath/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0)

_Kopiert von der ursprünglichen Ausgabe: AdoptOpenJDK / openjdk-jdk8u-backup # 4_

bug
Quelle
picture karianna

Hilfreichster Kommentar

Anzeigen eines möglicherweise verwandten Fehlers unter MacOS 10.13.6 mit AdoptOpenJDK jdk8u172-b11
Das Einrichten eines Symlinks ist eine Problemumgehung für das Problem:
ln -s libfreetype.dylib.6 libfreetype.6.dylib

Stacktrace
Exception in thread "main" java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/jdk8u172-b11/jre/lib/libfontmanager.dylib: dlopen(/Library/Java/JavaVirtualMachines/jdk8u172-b11/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib Referenced from: /Library/Java/JavaVirtualMachines/jdk8u172-b11/jre/lib/libfontmanager.dylib Reason: image not found at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:93)

picture pdl3 am 28. Sept. 2018
👍11 🎉3

Alle 26 Kommentare

Von @Diagoras am 6. September 2018 16: 53_

FWIW, ich habe das gleiche Problem. Derzeit wird verhindert, dass eine Anwendung auf AdoptOpenJDK migriert wird.

karianna picture karianna am 10. Sept. 2018

@johnoliver LMK, wenn Sie möchten, dass dies als Fehler in das Build-Repo verschoben wird

karianna picture karianna am 10. Sept. 2018

_Von @johnoliver am 7. September 2018 12: 15_

Ich denke, dies wurde behoben. Können Sie eine aktuelle Binärdatei von https://github.com/AdoptOpenJDK/openjdk8-binaries/releases ausprobieren

karianna picture karianna am 10. Sept. 2018

Von @Diagoras am 10. September 2018 19: 36_

@johnoliver Hey, ich habe es mit dem Hotspot jdk8u-2018-07-26-16-12 für MacOS versucht, bin aber auf dasselbe Problem gestoßen. Speziell:

Fatal(java.lang.UnsatisfiedLinkError: /Users/[username]/Downloads/jdk8u181-b13/jre/lib/libfontmanager.dylib: dlopen(/Users/[username]/Downloads/jdk8u181-b13/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib
  Referenced from: /Users/[username]/Downloads/jdk8u181-b13/jre/lib/libfontmanager.dylib
  Reason: image not found
)

Können wir dieses Problem erneut öffnen?

karianna picture karianna am 10. Sept. 2018

Wiedereröffnet, aber ich werde es auf das Build-Repo verschieben

karianna picture karianna am 10. Sept. 2018

Anzeigen eines möglicherweise verwandten Fehlers unter MacOS 10.13.6 mit AdoptOpenJDK jdk8u172-b11
Das Einrichten eines Symlinks ist eine Problemumgehung für das Problem:
ln -s libfreetype.dylib.6 libfreetype.6.dylib

Stacktrace
Exception in thread "main" java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/jdk8u172-b11/jre/lib/libfontmanager.dylib: dlopen(/Library/Java/JavaVirtualMachines/jdk8u172-b11/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib Referenced from: /Library/Java/JavaVirtualMachines/jdk8u172-b11/jre/lib/libfontmanager.dylib Reason: image not found at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1122) at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:93)

pdl3 picture pdl3 am 28. Sept. 2018
👍11 🎉3

Beim Build jdk8u181-b13 besteht weiterhin ein Problem:

java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/jdk8u181-b13/Contents/Home/jre/lib/libfontmanager.dylib: dlopen(/Library/Java/JavaVirtualMachines/jdk8u181-b13/Contents/Home/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib
  Referenced from: /Library/Java/JavaVirtualMachines/jdk8u181-b13/Contents/Home/jre/lib/libfontmanager.dylib
  Reason: image not found

Der tatsächliche lib-Name stimmt nicht mit rpath überein:

$ ls /Library/Java/JavaVirtualMachines/jdk8u181-b13/Contents/Home/jre/lib/libfreetype*
/Library/Java/JavaVirtualMachines/jdk8u181-b13/Contents/Home/jre/lib/libfreetype.dylib.6
zman0900 picture zman0900 am 18. Okt. 2018

Ich bin gerade auf dieses Problem gestoßen, weil wir eine Abhängigkeit vom Apache-POI haben, sodass wir nicht migrieren können, um Open JDK 8 zu übernehmen ...

Alasiac picture Alasiac am 18. Okt. 2018

Gibt es eine kurze / einfache Reproduzierbarkeit, die ich ausprobieren kann?

karianna picture karianna am 18. Okt. 2018

Hier ein grundlegendes Beispiel dafür, was die Ausnahme auslöst:

poi-example.zip

Das Beispiel läuft auf einem Oracle jdk8.

Stapelverfolgung beim Ausführen des Tests:

runningPoiResultsInLinkError (com.example.poi.link.PoiLinkTest) Verstrichene Zeit: 0,958 Sek. <<< FEHLER!
java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/lib/libfontmanager.dylib: dlopen (/Library/Java/JavaVirtualMachines/adoptopenjd / jre / lib / libfontmanager.dylib, 1): Bibliothek nicht geladen: @ rpath / libfreetype.6.dylib
Referenziert von: /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/lib/libfontmanager.dylib
Grund: Bild nicht gefunden
at java.lang.ClassLoader $ NativeLibrary.load (native Methode)
at java.lang.ClassLoader.loadLibrary0 (ClassLoader.java:1941)
bei java.lang.ClassLoader.loadLibrary (ClassLoader.java:1845)
at java.lang.Runtime.loadLibrary0 (Runtime.java:870)
bei java.lang.System.loadLibrary (System.java:1122)
at sun.font.FontManagerNativeLibrary $ 1.run (FontManagerNativeLibrary.java:61)
at java.security.AccessController.doPrivileged (native Methode)
bei sun.font.FontManagerNativeLibrary.(FontManagerNativeLibrary.java:32)
at sun.font.SunFontManager $ 1.run (SunFontManager.java:339)
at java.security.AccessController.doPrivileged (native Methode)
bei sun.font.SunFontManager.(SunFontManager.java:335)
at java.lang.Class.forName0 (native Methode)
bei java.lang.Class.forName (Class.java:348)
at sun.font.FontManagerFactory $ 1.run (FontManagerFactory.java:82)
at java.security.AccessController.doPrivileged (native Methode)
at sun.font.FontManagerFactory.getInstance (FontManagerFactory.java:74)
bei java.awt.Font.getFont2D (Font.java:491)
bei java.awt.Font.canDisplayUpTo (Font.java:2060)
at java.awt.font.TextLayout.singleFont (TextLayout.java:470)
bei java.awt.font.TextLayout.(TextLayout.java:531)
at org.apache.poi.ss.util.SheetUtil.getColumnWidth (SheetUtil.java:208)
at org.apache.poi.xssf.streaming.SXSSFSheet.autoSizeColumn (SXSSFSheet.java:1166)
at org.apache.poi.xssf.streaming.SXSSFSheet.autoSizeColumn (SXSSFSheet.java:1148)
at com.example.poi.link.PoiLinkTest.runningPoiResultsInLinkError (PoiLinkTest.java:14)

Alasiac picture Alasiac am 19. Okt. 2018
👍2

Das Gleiche gilt hier, Swing funktioniert nicht mit u192-b12 (Hinweis: Ich bin bei der Migration von OracleJDK darauf gestoßen):

Exception in thread "main" java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/jdk8u192-b12/Contents/Home/jre/lib/libfontmanager.dylib: dlopen(/Library/Java/JavaVirtualMachines/jdk8u192-b12/Contents/Home/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib
  Referenced from: /Library/Java/JavaVirtualMachines/jdk8u192-b12/Contents/Home/jre/lib/libfontmanager.dylib
  Reason: image not found
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:93)
    at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:80)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.lwawt.macosx.LWCToolkit.<clinit>(LWCToolkit.java:79)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at java.awt.Toolkit$2.run(Toolkit.java:860)
    at java.awt.Toolkit$2.run(Toolkit.java:855)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)
    at java.awt.Window.getToolkit(Window.java:1358)
    at java.awt.Window.init(Window.java:506)
    at java.awt.Window.<init>(Window.java:436)
    at java.awt.Frame.<init>(Frame.java:446)
    at java.awt.Frame.<init>(Frame.java:404)
    at javax.swing.JFrame.<init>(JFrame.java:213)
slandelle picture slandelle am 5. Nov. 2018

Ich habe das gleiche Problem. Selbst mit so einfachem Code (läuft mit Netbeans):

public class JavaApplication4 {
    /**
     * <strong i="6">@param</strong> args the command line arguments
     */
    public static void main(String[] args) {
        System.out.println(" Hello !");

        JFrame frame = new JFrame("Testando");
        frame.setVisible(true);
        frame.setSize(300, 300);
    }
}

run:
 Hello !
Exception in thread "main" java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/jdk8u192-b12/Contents/Home/jre/lib/libfontmanager.dylib: dlopen(/Library/Java/JavaVirtualMachines/jdk8u192-b12/Contents/Home/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib
  Referenced from: /Library/Java/JavaVirtualMachines/jdk8u192-b12/Contents/Home/jre/lib/libfontmanager.dylib
  Reason: image not found
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:93)
    at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:80)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.lwawt.macosx.LWCToolkit.<clinit>(LWCToolkit.java:79)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at java.awt.Toolkit$2.run(Toolkit.java:860)
    at java.awt.Toolkit$2.run(Toolkit.java:855)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)
    at java.awt.Window.getToolkit(Window.java:1358)
    at java.awt.Window.init(Window.java:506)
    at java.awt.Window.<init>(Window.java:537)
    at java.awt.Frame.<init>(Frame.java:420)
    at javax.swing.JFrame.<init>(JFrame.java:233)
    at javaapplication4.JavaApplication4.main(JavaApplication4.java:23)
/Users/gabriela/Library/Caches/NetBeans/8.2/executor-snippets/run.xml:53: Java returned: 1
BUILD FAILED (total time: 3 seconds)

Aus diesem Grund kann ich nicht zu AdoptOpenJDK migrieren.

gabibau picture gabibau am 5. Dez. 2018

Die Problemumgehung besteht darin, einen Symlink zu erstellen: libfreetype.6.dylib -> libfreetype.dylib.6

slandelle picture slandelle am 6. Dez. 2018
👍2

@slandelle Ist die Hauptursache nur, dass der Dateiname "6" und "dylib" in der falschen Reihenfolge hat? Denn das ist ziemlich lustig und hoffentlich eine einfache Lösung.

Diagoras picture Diagoras am 6. Dez. 2018

Es scheint ein subtiler Unterschied zwischen den Versionen von Mac OS X zu sein. Wir hoffen, dass dies nächste Woche für zukünftige Builds behoben wird!

karianna picture karianna am 7. Dez. 2018
👍2

Die Problemumgehung besteht darin, einen Symlink zu erstellen: libfreetype.6.dylib -> libfreetype.dylib.6

Es funktioniert hier. Ich hoffe, es hilft, das Problem bald zu beheben.
Vielen Dank!

gabibau picture gabibau am 10. Dez. 2018

1 CD zum JDK-Pfad lib "/ Contents / Home / jre / lib"

2 dann "sudo ln -s libfreetype.dylib.6 libfreetype.6.dylib"

Es hat bei mir funktioniert.

Cynthiahaha picture Cynthiahaha am 11. Dez. 2018
👍10 😄2

Der Versuch, Groovys groovysh - das kein GUI-Tool ist - auf AdoptOpenJDK 8 auszuführen, löst außerdem Folgendes aus:

$ groovysh
java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:110)
    at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128)
Caused by: java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/openjdk8/Contents/Home/jre/lib/libfontmanager.dylib: dlopen(/Library/Java/JavaVirtualMachines/openjdk8/Contents/Home/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib
  Referenced from: /Library/Java/JavaVirtualMachines/openjdk8/Contents/Home/jre/lib/libfontmanager.dylib
  Reason: image not found
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1845)
    at java.lang.Runtime.loadLibrary0(Runtime.java:870)
    at java.lang.System.loadLibrary(System.java:1122)
    at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:93)
    at sun.lwawt.macosx.LWCToolkit$1.run(LWCToolkit.java:80)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.lwawt.macosx.LWCToolkit.<clinit>(LWCToolkit.java:79)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at java.awt.Toolkit$2.run(Toolkit.java:860)
    at java.awt.Toolkit$2.run(Toolkit.java:855)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)
    at java.awt.Desktop.isDesktopSupported(Desktop.java:169)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:104)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:326)
    at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1859)
    at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3797)
    at org.codehaus.groovy.runtime.callsite.ClassMetaClassGetPropertySite.getProperty(ClassMetaClassGetPropertySite.java:50)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:298)
    at org.codehaus.groovy.tools.shell.commands.DocCommand.<clinit>(DocCommand.groovy:53)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
    at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:249)
    at org.codehaus.groovy.tools.shell.util.DefaultCommandsRegistrar.register(DefaultCommandsRegistrar.groovy:84)
    at org.codehaus.groovy.tools.shell.util.DefaultCommandsRegistrar$register.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:119)
    at org.codehaus.groovy.tools.shell.Groovysh$_createDefaultRegistrar_closure3.doCall(Groovysh.groovy:121)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:104)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:326)
    at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:41)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:127)
    at org.codehaus.groovy.tools.shell.Groovysh.<init>(Groovysh.groovy:109)
    at org.codehaus.groovy.tools.shell.Groovysh.<init>(Groovysh.groovy:140)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
    at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:257)
    at org.codehaus.groovy.tools.shell.Main.<init>(Main.groovy:65)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
    at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:237)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:257)
    at org.codehaus.groovy.tools.shell.Main.main(Main.groovy:158)
    ... 6 more

Das Erstellen des von @Cynthiahaha vorgeschlagenen

Dieses groovysh -Problem tritt bei Verwendung eines AdoptOpenJDK 11-Builds (HotSpot oder OpenJ9) nicht auf.

breun picture breun am 26. Dez. 2018

Ist die Grundursache nur, dass der Dateiname "6" und "dylib" in der falschen Reihenfolge hat? Denn das ist ziemlich lustig und hoffentlich eine einfache Lösung.

Es scheint ein subtiler Unterschied zwischen den Versionen von Mac OS X zu sein

Unter Nicht-MacOS-UNIX-ähnlichen Betriebssystemen lautet das Suffix der gemeinsam genutzten Bibliothek "so" und tritt vor einer beliebigen Versionsnummer auf (z. B. "libfreetype.so.6"). Unter macOS lautet das dynamische Bibliothekssuffix "dylib" und tritt nach der optionalen Hauptversionsnummer (z. B. "libfreetype.6.dylib") auf. Alle Versionen von macOS folgen dieser Konvention. Wahrscheinlich gibt es irgendwo im Build-System eine Annahme, dass die Versionsnummer nach dem Suffix angezeigt wird, wenn beim Erstellen unter macOS falsch angewendet wird.

ryandesign picture ryandesign am 11. Jan. 2019
👍1

1 CD zum JDK-Pfad lib "/ Contents / Home / jre / lib"

2 dann "sudo ln -s libfreetype.dylib.6 libfreetype.6.dylib"

Es hat bei mir funktioniert.

Vielen Dank für diese Problemumgehung. Dies betraf auch das Erstellen von PDFs (über einen Backend-Dienst), nicht nur über eine GUI-App.

justinnichols picture justinnichols am 14. Jan. 2019
👍2

@helenmasters @justinnichols @ryandesign @breun @Cynthiahaha @gabibau und alles, was Sie bitte versuchen können

Können Sie das JDK / JRE unter folgender Adresse testen:

karianna picture karianna am 15. Jan. 2019

@karianna Sie scheinen das Problem zu beheben, das ich beim Ausführen von groovysh .

Ich habe festgestellt, dass diese Builds sowohl libfreetype.6.dylib als auch libfreetype.dylib.6 und nicht identisch sind:

$ ls -l libfreetype.*
-rwxr-xr-x@ 1 breun  staff  873072 15 jan 18:38 libfreetype.6.dylib
-rwxr-xr-x@ 1 breun  staff  873088 15 jan 18:38 libfreetype.dylib.6

Ist das notwendig / beabsichtigt?

breun picture breun am 16. Jan. 2019

@karianna Sie scheinen das Problem zu beheben, das ich beim Ausführen von groovysh .

Ich habe festgestellt, dass diese Builds sowohl libfreetype.6.dylib als auch libfreetype.dylib.6 und nicht identisch sind:

$ ls -l libfreetype.*
-rwxr-xr-x@ 1 breun  staff  873072 15 jan 18:38 libfreetype.6.dylib
-rwxr-xr-x@ 1 breun  staff  873088 15 jan 18:38 libfreetype.dylib.6

Ist das notwendig / beabsichtigt?

@ Johnoliver Gleiche Frage wie bei anderen Ausgaben.

karianna picture karianna am 16. Jan. 2019

denke, das ist erledigt

johnoliver picture johnoliver am 23. Jan. 2019

kann es geschlossen werden @johnoliver

gdams picture gdams am 23. Jan. 2019

Ich denke schon, kann wieder geöffnet werden, wenn jemand ein Problem hat

johnoliver picture johnoliver am 24. Jan. 2019
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

pshipton picture pshipton  ·  4Kommentare
adam-thorpe picture adam-thorpe  ·  7Kommentare
sophia-guo picture sophia-guo  ·  6Kommentare
agilob picture agilob  ·  6Kommentare
sxa picture sxa  ·  4Kommentare