Temurin-build: Mettre à jour les scripts de construction avec l'emplacement de libfreetype.6.dylib

J'ai examiné ce problème et j'ai trouvé que libfreetype.6.dylib n'est pas une bibliothèque dépendante du chemin d'exécution. En conséquence, libfontmanager.dylib est lié au nom_installation complet de la bibliothèque.

Bhaktavatsals-MacBook-Pro:sdk mbvreddy$ otool -L /Users/mbvreddy/workarea/JDK/OPENJ9/jdk-9+181/lib/libfontmanager.dylib 
/Users/mbvreddy/workarea/JDK/OPENJ9/jdk-9+181/lib/libfontmanager.dylib:
    @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0)
    /Users/jenkins/workspace/openjdk9_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)
    @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)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)

Toutes les autres bibliothèques faisant partie de JDK sont créées en tant que bibliothèques dépendantes du chemin d'exécution. Par exemple libawt.dylib, libjava.dylib ...

Comme libfreetype.6.dylib est généré en dehors de JDK, il est nécessaire de changer l'indicateur LINKER -install_name /Users/jenkins/workspace/openjdk9_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib

à

-install_name @rpath/libfreetype.6.dylib

J'ai essayé de voir s'il y avait une option de configuration dans freetype-2.4.0 pour changer install_name en @rpath. Je n'ai pas pu en trouver. Alternativement, nous pouvons utiliser la commande suivante pour changer le nom_installation de libfreetype.6.dylib

install_name_tool -id @rpath/libfreetype.6.dylib /Users/jenkins/workspace/openjdk_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib

libfreetype.dylib.6 présente dans jdk / lib n'est pas une bibliothèque valide sur Mac. Un autre changement est nécessaire pour le copier sous libfreetype.6.dylib

@mbvreddy Merci d'avoir mené l'enquête sur ce problème. Je vais essayer d'utiliser vos suggestions et revenir dès que possible.

@mbvreddy Pouvez-vous m'expliquer ce que vous entendez par ceci:

Comme libfreetype.6.dylib est généré en dehors de JDK, il est nécessaire de changer l'indicateur LINKER -install_name /Users/jenkins/workspace/openjdk9_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib

à

-nom_installation @ rpath / libfreetype.6.dylib

À quelle application le drapeau -install_name est-il passé?

La commande ci-dessous:

install_name_tool -id @rpath/libfreetype.6.dylib /Users/jenkins/workspace/openjdk_build_x86-64_macos/openjdk/installedfreetype/lib/libfreetype.6.dylib

Ne donne pas de commentaire si cela a fonctionné ou non, revient simplement à l'invite.

Quelle commande avez-vous utilisée pour trouver le chemin d'exécution attaché à cette bibliothèque dynamique? Comme le chemin est intégré dans le binaire lui-même.

Ce serait formidable d'obtenir des réponses à ce qui précède.

install_name_tool ne donne aucune sortie. Mais vous pouvez utiliser otool -L <library> pour vérifier si le chemin d'exécution est activé ou non. Il devrait afficher quelque chose comme @rpath/libfreetype.6.dylib

Il y a un autre problème à prendre en compte comme mentionné dans https://github.com/AdoptOpenJDK/openjdk-build/issues/202#issuecomment -361487575

À quelle application l'indicateur -install_name est-il passé?

Afin de changer -install_name pour utiliser @rpath , nous devons modifier le makefile freetype qui ne semble pas être une option réalisable ici. Donc, j'ai trouvé que nous pourrions utiliser install_name_tool pour résoudre ce problème après la construction de la bibliothèque.

@mbvreddy merci pour tous les commentaires, nous les avons utilisés pour les appliquer pour arriver à notre correctif

Clôture comme maintenant répertoriée dans le numéro de synthèse # 346

Ce bogue existe toujours dans l'OpenJDK8_x64_Mac_jdk8u172-b11.tar.gz actuellement disponible au téléchargement:

Partie de stacktrace lors de la tentative de chargement de libfontmanager.dylib:

!ENTRY org.eclipse.ui 4 0 2018-09-24 13:39:28.488
!MESSAGE Unhandled event loop exception
!STACK 0
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.UnsatisfiedLinkError: /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib: dlopen(/Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib, 1): Library not loaded: @rpath/libfreetype.6.dylib
  Referenced from: /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib
  Reason: image not found)

Afficher la version Java:

$ /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/bin/java -version
openjdk version "1.8.0-adoptopenjdk"
OpenJDK Runtime Environment (build 1.8.0-adoptopenjdk-jenkins_2018_05_19_02_01-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

Afficher la configuration de l'éditeur de liens pour libfontmanager.dylib, avec un lien vers @ rpath / libfreetype.6.dylib :

$ otool -L /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib
/Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfontmanager.dylib:
    @rpath/libfontmanager.dylib (compatibility version 1.0.0, current version 1.0.0)
    @rpath/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)

Afficher le nom de fichier libfreetype inclus à être nommé à tort comme libfreetype.dylib.6

$ find /Library/Java/ -type f -name *libfreetype*
/Library/Java//JavaVirtualMachines/1.8.0.jdk/Contents/Home/jre/lib/libfreetype.dylib.6

@ rubin55 Oui, ces binaires ont été produits sous les anciens scripts de construction. Pouvez-vous essayer une version nocturne:

https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u-2018-09-24-11-44/OpenJDK8U_x64_mac_hotspot_2018-09-24-11-44.tar.gz

Salut @karianna , mmm semble toujours être un problème là-bas:

$ tar tvzf OpenJDK8U_x64_mac_hotspot_2018-09-24-11-44.tar.gz | grep -i freetype
-rwxr-xr-x  0 jenkins staff   696128 Sep 23 09:03 ./jdk8u181-b13/jre/lib/libfreetype.dylib.6

D'accord merci.

Salut @karianna , au 30 novembre, c'est toujours un problème avec la version nocturne pour Mac OS:

$ tar tvzf OpenJDK8U-jdk_x64_mac_openj9_2018-11-29-11-20.tar | grep -i freetype
-rwxr-xr-x  0 jenkins staff   872912 29 Nov 09:48 jdk8u192-b12/Contents/Home/jre/lib/libfreetype.dylib.6

Coretto a eu le même problème que nous: https://github.com/corretto/corretto-8/issues/6

Quelqu'un pourrait-il fournir un résumé de ce qui se passe avec ce bogue, en particulier pour JDK 8 s'il vous plaît?
Nous pensions que le précédent PR n ° 225 avait résolu le problème, mais ce n'était pas le cas, ou le PR a résolu le problème pour JDK 11, mais pas pour JDK 8? Y a-t-il quelqu'un qui travaille là-dessus, sinon y a-t-il quelque chose que la communauté peut aider? Merci.

@ eed3si9n @ksilz @ rubin55 @smlambert

Pouvez-vous essayer le JDK / JRE sur: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-mac-x64-hotspot/148/

@karianna Je vois libfreetype.6.dylib et libfreetype.dylib.6 sous Contents/Home/jre/lib avec une taille de fichier légèrement différente:

-rwxr-xr-x@  1 xxx  staff    873072 Jan 15 12:38 libfreetype.6.dylib*
-rwxr-xr-x@  1 xxx  staff    873088 Jan 15 12:38 libfreetype.dylib.6*

Cela a-t-il du sens?

@karianna Je vois libfreetype.6.dylib et libfreetype.dylib.6 sous Contents/Home/jre/lib avec une taille de fichier légèrement différente:

-rwxr-xr-x@  1 xxx  staff    873072 Jan 15 12:38 libfreetype.6.dylib*
-rwxr-xr-x@  1 xxx  staff    873088 Jan 15 12:38 libfreetype.dylib.6*

Cela a-t-il du sens?

@johnoliver Y a-t-il une explication raisonnable à cela? J'aurais pensé qu'une copie devrait signifier == octets.

La dernière compilation nocturne OpenJDK8U-jdk_x64_mac_openj9_2019-01-21-09-29.tar.gz affiche toujours deux fichiers différents avec des tailles différentes. Je pense qu'il ne devrait y avoir que libfreetype.6.dylib :

lib  $ ls -al *freetype*
-rwxr-xr-x  1 karsten  staff  872896 21 Jan 10:24 libfreetype.6.dylib
-rwxr-xr-x  1 karsten  staff  872912 21 Jan 10:24 libfreetype.dylib.6

Je crois que la différence de taille a été introduite lors de la signature