Mac OS X El Capitan peut-il exécuter un logiciel compilé pour Yosemite qui attend des bibliothèques dans / usr / gnu64 / lib?

Désolé, un peu de fond est nécessaire – vous pouvez essayer de passer directement à l’en-tête de la question .

Depuis des temps immémoriaux (quelque part au cours du dernier millénaire), j’ai créé des répertoires tels que /usr/gnu et /usr/gcc pour contenir un logiciel GNU compilé sur mesure, distinct de tout élément des répertoires système. Cela a bien fonctionné pour moi sur une grande variété de systèmes Unix, y compris Mac OS X depuis 2002 (Jaguar, 10.2). (Une des raisons de ne pas utiliser /usr/local était que la gestion informatique le maintenait et qu’il contenait toujours du code archaïque – il disposait de Perl 4 jusqu’à il y a environ 5 ans, par exemple. L’utilisation d’autres noms évitait les incidents avec eux.)

Avec Mac OS X 10.11 El Capitan, Apple a introduit le système SIP (System Integrity Protection) (décrit dans Qu’est-ce que la fonctionnalité “sans racine” d’El Capitan, vraiment? Sur “Ask Different”). Cela signifie que je ne peux plus créer de répertoires tels que /usr/gnu ou /usr/gcc , même s’ils sont disjoints de tout ce que Apple possède.

J’ai constaté que le logiciel qui se trouvait auparavant dans ces répertoires avait été mis en quarantaine dans des répertoires tels que ceux-ci (les UUID seront différents sur votre ordinateur, et j’en ai probablement deux car mettre El Capitan sur cet ordinateur était une opération à plusieurs étapes – une opération longue et séparée. histoire ennuyeuse):

 $ ls -1 /Library/SystemMigration/History/ Migration-7D74B534-AA54-4A4A-8DCC-A5C2F28E1A39 Migration-9C0FE7A4-3445-4BD6-A512-35464EECCBC3 $ 

puis dans les sous-répertoires sous QuarantineRoot :

 $ ls /Library/SystemMigration/History/Migration-9C0FE7A4-3445-4BD6-A512-35464EECCBC3/QuarantineRoot/usr: gcc gnu32 gnu64 $ 

Cependant, les fichiers binarys ont été compilés avec GCC et diverses bibliothèques, ils ne sont donc pas exécutés pour le moment. Par exemple:

 $ otool -L bison bison: /usr/gnu64/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.1.0) /usr/gnu64/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.18.0) /usr/gcc/v4.7.1/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) $ ./bison dyld: Library not loaded: /usr/gnu64/lib/libintl.8.dylib Referenced from: /Library/SystemMigration/History/Migration-9C0FE7A4-3445-4BD6-A512-35464EECCBC3/QuarantineRoot/usr/gnu64/bin/./bison Reason: image not found Trace/BPT trap: 5 $ 

Autant que je sache, je ne peux même pas créer de liens symboliques dans /usr tels que gcc ou gnu64 pointe ailleurs (même avec des privilèges root). C’est l’une des techniques que j’ai utilisées pour créer un logiciel sur MachineA avec un espace disponible dans /work1 pour une utilisation sur un autre MachineB avec un espace disponible dans /work5 ; un lien symbolique dans /usr permet au code de s’asseoir dans /work1/gcc ou /work5/gcc et il fonctionne correctement tant que /usr/gcc pointe sur l’emplacement où les fichiers sont réellement installés. Ainsi, ce système SIP semble détruire tous les mécanismes utilisés avec succès pendant quelques décennies, supposés être capables de créer au moins une sorte d’entrée de répertoire dans /usr .

Question

  • Existe-t-il un moyen judicieux de faire fonctionner les anciens fichiers binarys sans désactiver SIP et sans avoir à tout recomstackr immédiatement?

La position de repli est “recomstackr le logiciel – en évitant /usr comme emplacement d’installation”. Avec le temps, je prévois d’utiliser /opt/gcc et /opt/gnu64 au lieu des équivalents sous /usr . J’envisage même d’utiliser de l’espace dans mon répertoire personnel, même si je préfère ne pas le faire. c’est un logiciel ‘système’.

Cependant, j’ai pas mal de logiciels déjà compilés, y compris plusieurs versions de GCC (de 4.4.2 à 5.2.0), qu’il serait gênant de recomstackr. En fait, je vais devoir abandonner les anciennes versions de GCC, que je n’utilise pas souvent, mais qui sont utiles lorsque j’en ai besoin.


Oh, et j’ai un problème avec le script de configuration pour GNU Tar (1.28 et 1.26). Il teste la profondeur de création d’une arborescence de répertoires et est ensuite incapable de le nettoyer. Et ni rm ni rmdir ne peuvent nettoyer non plus, même si je descends la hiérarchie au fond. Il y a une erreur ‘manque d’espace disque’, même s’il rest beaucoup d’espace. Je peux utiliser le Finder pour déplacer la hiérarchie dans la corbeille. Mais Finder ne peut pas les supprimer non plus. Bash a un tizzy parce qu’il ne peut pas savoir quel est le répertoire actuel. C’est un peu douloureux! Donc, recomstackr et réinstaller certains des logiciels ne va pas être sortingvial. Je peux même finir par utiliser des éléments compilés par d’autres personnes (MacPorts, HomeBrew, etc.), mais j’aime bien pouvoir le faire moi-même. Je reçois le message d’erreur ‘L’opération ne peut pas être terminée car l’élément “confdir-14B —” est en cours d’utilisation ”; un redémarrage peut être dans l’ordre, mais je ne suis pas convaincu que cela résoudra ce problème.

    Juste pour des raisons de fermeture:

    • Non; il ne semble pas y avoir de moyen d’éviter de recomstackr le code.

    Si vous souhaitez suivre le lien de discussion, faites-le, mais la conclusion sera la même.