Temurin-build: Native Libraries können nicht mit 11.0.4 auf Mojave geladen werden

Erstellt am 9. Aug. 2019 · 19Kommentare · Quelle: adoptium/temurin-build

Plattform:

OSX Mojave

Darwin Kernel Version 18.7.0: Do 20. Juni 18:42:21 PDT 2019; root: xnu-4903.270.47 ~ 4 / RELEASE_X86_64

Die Architektur:

x86_64

Fehlerbeschreibung

Beim Versuch, native Bibliotheken mit einem der 11.0.4-Builds auf die oben genannte Plattform zu laden, tritt eine Ausnahme auf:

/private/var/folders/f6/c8gfypz56c5d9b66l6_1n30m0000gn/T/native-platform4313193693498570932dir/libnative-platform.dylib: code signature in (/private/var/folders/f6/c8gfypz56c5d9b66l6_1n30m0000gn/T/native-platform4313193693498570932dir/libnative-platform.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.

Bei der Ausführung mit 11.0.3 funktioniert alles wie erwartet.

Reproduzierbarer Test

Hier gibt es eine Java-App: https://bintray.com/beta/#/adammurdoch/maven/net.rubygrapefruit : native-platform-test / 0.18? Tab = Dateien, die verschiedene native Aufrufe testen.

Wenn Sie die Zip-Datei herunterladen und auspacken, erhalte ich die folgenden Ergebnisse:

11.0.3 ( gut )

$ bin/native-platform-test

Select test to run:
  1) Show terminal details
  2) Show machine details
  3) Show file systems
  4) Test input handling
  5) Example prompts
> 6) Exit
Use the arrow keys to select an option and press enter

11.0.4 ( schlecht )

$ bin/native-platform-test
Exception in thread "main" net.rubygrapefruit.platform.NativeIntegrationLinkageException: Native library 'libnative-platform.dylib' could not be loaded for Mac OS X x86_64.
    at net.rubygrapefruit.platform.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:61)
    at net.rubygrapefruit.platform.Native.init(Native.java:55)
    at net.rubygrapefruit.platform.Native.get(Native.java:80)
    at net.rubygrapefruit.platform.test.Main.terminals(Main.java:286)
    at net.rubygrapefruit.platform.test.Main.main(Main.java:109)
Caused by: java.lang.UnsatisfiedLinkError: /private/var/folders/f6/c8gfypz56c5d9b66l6_1n30m0000gn/T/native-platform4313193693498570932dir/libnative-platform.dylib: dlopen(/private/var/folders/f6/c8gfypz56c5d9b66l6_1n30m0000gn/T/native-platform4313193693498570932dir/libnative-platform.dylib, 1): no suitable image found.  Did find:
    /private/var/folders/f6/c8gfypz56c5d9b66l6_1n30m0000gn/T/native-platform4313193693498570932dir/libnative-platform.dylib: code signature in (/private/var/folders/f6/c8gfypz56c5d9b66l6_1n30m0000gn/T/native-platform4313193693498570932dir/libnative-platform.dylib) not valid for use in process using Library Validation: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed.
    at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
    at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2430)
    at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2487)
    at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
    at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2617)
    at java.base/java.lang.Runtime.load0(Runtime.java:767)
    at java.base/java.lang.System.load(System.java:1831)
    at net.rubygrapefruit.platform.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:51)
    ... 4 more

Ich vermute, dass dies nur ein OS X ist, aber ich teste es auf Ubuntu, um sicherzugehen

bug macos

Quelle

timyates

Hilfreichster Kommentar

@taubeklavs Wir haben eine Lösung dafür und sind dabei, eine jdk-11.0.4+11.3 -Veröffentlichung zu erstellen. Entschuldigung für die Unannehmlichkeiten

gdams am 13. Aug. 2019

👍8

Alle 19 Kommentare

Unter Ubuntu getestet und beide Versionen funktionieren wie erwartet ...

Dies scheint nur ein OS X-Problem zu sein

timyates am 9. Aug. 2019

Ich habe auch das gleiche Problem auf Macos mit jdk-11.0.4+11.2 , das auf jdk-11.0.3+7 .

taubeklavs am 9. Aug. 2019

👍1

@gdams hängt wahrscheinlich mit den anderen Problemen zusammen, an denen Sie arbeiten ...

karianna am 13. Aug. 2019

@taubeklavs Wir haben eine Lösung dafür und sind dabei, eine jdk-11.0.4+11.3 -Veröffentlichung zu erstellen. Entschuldigung für die Unannehmlichkeiten

gdams am 13. Aug. 2019

👍8

Super danke! 😎👍

Ich bin mir nicht sicher, wie ich https://github.com/AdoptOpenJDK/openjdk-build/issues/1206 verpasst habe

timyates am 13. Aug. 2019

Sieht nicht so aus, als wäre der Build noch nicht fertig und das Problem hat etwas blockiert, an dem ich arbeite. Für alle anderen im selben Boot sollten Sie in der Lage sein:

brew cask reinstall https://raw.githubusercontent.com/AdoptOpenJDK/homebrew-openjdk/c017a832eec4f940e11c139b6e7852eeb3b2aad8/Casks/adoptopenjdk11.rb

um das adoptopenjdk11 Fass so vorzulesen:

$ brew cask info adoptopenjdk11
adoptopenjdk11: 11,0.3:7
https://adoptopenjdk.net/
/usr/local/Caskroom/adoptopenjdk11/11,0.3:7 (181.4MB)
From: https://github.com/adoptopenjdk/homebrew-openjdk/blob/master/Casks/adoptopenjdk11.rb
==> Name
AdoptOpenJDK 11
==> Artifacts
OpenJDK11U-jdk_x64_mac_hotspot_11.0.3_7.pkg (Pkg)

Sobald der neue Build veröffentlicht ist, sollte ihn einfaches brew cask upgrade abholen. :) :)

sjuxax am 14. Aug. 2019

👍6

Speichern fehlerhaftes Verhalten tritt mit auf

openjdk version "12.0.2" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 12.0.2+10)

Ich habe gerade jdk-12.0.2+10.2 heruntergeladen und native-platform-test . Ich habe die von OP gemeldete "Bad" -Spur erhalten.

Hoffnung auf einen festen Build?

bberstel am 19. Aug. 2019

👍3

Hallo, kann dies auch auf der Version 12 bestätigen.

ktulinger am 1. Okt. 2019

Habe gerade den neuesten 11.0.5 überprüft

openjdk version "11.0.5" 2019-10-15

Und das alles funktioniert unter OS X 😎 🎉

Schließen Sie dies

Vielen Dank an alle!

timyates am 15. Nov. 2019

👍1

Ich habe dieses Problem mit 14.0.1 und 11.0.7 auf Catalina

MRigal am 1. Mai 2020

👍1

@MRigal Wie haben Sie die Binärdatei installiert - war es eine PKG-Datei über Homebrew?

karianna am 1. Mai 2020

Beide Versionen werden über Homebrew installiert. Ich habe auch die empfohlenen Symlinks hinzugefügt
nach der Installation.
brew install java und brew install java11

MRigal am 1. Mai 2020

Ich habe immer noch dieses Problem mit adoptopenjdk12 und osx Catalina

Betriebssystem: Mac OSX Catalina 10.15.4
jdk: installiert über

▶ brew tap adoptopenjdk/openjdk
▶ brew cask install adoptopenjdk --no-quarantine

Brew installierte das JDK unter /Library/Java/JavaVirtualMachines/

▶ java --version
openjdk 12.0.2 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 12.0.2+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 12.0.2+10, mixed mode)

sbt installiert über:

▶ brew install sbt

▶ sbt sbtVersion
[info]  1.3.10



md5-81688d6fdae4a4fb6cbfecc5b8fbee61



▶ sudo spctl --master-disable
▶ spctl --status
assessments disabled

# starting sbt will produce the same output (code signature in [...] not valid for use in process using Library Validation: mapped file has no cdhash)

▶ sudo spctl --master-enable
▶ spctl --status
assessments enabled



md5-046c5f6222d4ced024068ca879544f9b



▶ codesign -dv --verbose=4 ~/Library/Caches/JNA/temp/jna123.tmp
~/Library/Caches/JNA/temp/jna123.tmp: code object is not signed at all



md5-99fc43abd604e2213e80c0369e20444a



    <key>CFBundleSignature</key>
    <string>????</string>

Dies ist anscheinend die Standardeinstellung bei der Initialisierung neuer xcode-Projekte und wurde nicht geändert?!

peter-gerhard am 19. Mai 2020

@ peter-gerhard Auf OpenJDK 12 gibt es keine gehärtete Laufzeit- und Notarunterstützung, und es wird keine geben, weil es seine EOL erreicht hat.

aahlenst am 19. Mai 2020

😕1

Außerdem schließe ich dieses Problem, da die PKG von 11.0.7 vollständig notariell beglaubigt ist.

aahlenst am 19. Mai 2020

@aahlenst Ich habe herausgefunden, dass /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Info.plist nicht über die Bundle-Signatur verfügt.

<key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>11.0.7</string>

Welche Version ist derzeit mit Code signiert, da ich bereits die Versionen 11 und 12 ausprobiert habe?

vsgopinath am 11. Juni 2020

8u252.1, 11.0.7 und 14 sind notariell beglaubigt. Sie benötigen jedoch die PKG.

aahlenst am 11. Juni 2020

@aahlenst FYI dies wurde weder in 11.0.7 noch in 11.0.8 behoben, aber es ist in der Tat in 11.0.9 behoben

MRigal am 8. Jan. 2021

Wenn jemand beim Versuch, ein KMM-Projekt zu kompilieren, zu diesem Thread kam, konnte ich ihn beheben, indem ich die Gradle-Version auf 7.0.0-alpha09 aktualisierte.

cmota am 16. März 2021

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen

Temurin-build: Native Libraries können nicht mit 11.0.4 auf Mojave geladen werden

11.0.3 ( gut )

11.0.4 ( schlecht )

Hilfreichster Kommentar

Alle 19 Kommentare

Verwandte Themen