Tut mir leid, es ist ein bisschen Hintergrundwissen erforderlich - Sie können versuchen, zum @ zu springeFrag Überschrift.

eit undenklichen Zeiten (jedenfalls irgendwo im vorigen Jahrtausend) habe ich Verzeichnisse wie @ erstell/usr/gnu und/usr/gcc, um individuell kompilierte GNU-Software unabhängig von den Systemverzeichnissen zu speichern. Dies hat sich für mich auf einer Vielzahl von Unix-basierten Systemen bewährt, einschließlich Mac OS X seit 2002 (Jaguar, 10.2). (Ein Grund für die Nichtverwendung von/usr/local war, dass es vom IT-Management gewartet wurde und immer archaischen Code enthielt - Perl 4 war beispielsweise bis vor ungefähr 5 Jahren verfügbar. Durch die Verwendung anderer Namen konnten Run-Ins vermieden werden.)

it Mac OS X 10.11 El Capitan hat Apple das SIP-System (System Integrity Protection) eingeführt (beschrieben unterWas ist das "rootless" -Feature von El Capitan? auf 'Ask Different'). Das bedeutet, dass ich keine Verzeichnisse wie @ mehr erstellen kan/usr/gnu oder/usr/gcc, obwohl sie von allem, was Apple hat, unzusammenhängend sind.

Ich habe festgestellt, dass die Software, die sich zuvor in diesen Verzeichnissen befand, in solchen Verzeichnissen unter Quarantäne gestellt wurde (wobei die UUIDs auf Ihrem Computer unterschiedlich sein werden, und ich habe wahrscheinlich zwei, weil das Aufspielen von El Capitan auf diesen Computer ein mehrstufiger Vorgang war - ein separater langer Vorgang und langweilige Geschichte):

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

und dann in Unterverzeichnissen unterQuarantineRoot:

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

Die Binärdateien wurden jedoch mit GCC und verschiedenen Bibliotheken kompiliert, sodass sie derzeit nicht ausgeführt werden. Beispielsweise

$ 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
$

AFAIK, ich kann nicht einmal Symlinks in @ erstell/usr so dassgcc odergnu64 verweist auf einen anderen Ort (läuft nicht einmal mit root-Rechten). Das ist eine der Techniken, die ich verwendet habe, um Software auf MachineA mit freiem Speicherplatz in @ zu erstelle/work1 zur Verwendung auf einem anderen ComputerB mit freiem Speicherplatz in/work5; ein symlink in/usr erlaubt dem Code, in @ zu sitz/work1/gcc oder/work5/gcc und es funktioniert richtig, solange/usr/gcc zeigt an, wo die Dateien tatsächlich installiert sind. Dieses SIP-System scheint also alle seit einigen Jahrzehnten erfolgreich eingesetzten Mechanismen außer Kraft zu setzen, die darauf beruhen, dass mindestens ein Verzeichniseintrag in @ erstellt werden kan/usr.

Fragibt es eine sinnvolle Möglichkeit, die alten Binaries zum Laufen zu bringeohn SIP deaktivieren und ohne gleich alles neu kompilieren zu müssen?

Die Fallback-Position lautet "Software neu kompilieren - @ vermeid/usr als Installationsort ". Im Laufe der Zeit plane ich die Verwendung von/opt/gcc und/opt/gnu64 anstelle der Äquivalente unter/usr. Ich denke sogar darüber nach, Speicherplatz unter meinem Home-Verzeichnis zu belegen, obwohl ich es lieber nicht möchte. es ist "System" -Software.

Ich habe jedoch bereits eine ganze Menge Software kompiliert, einschließlich mehrerer Versionen von GCC (von 4.4.2 bis 5.2.0), deren Neukompilierung ein Ärgernis sein wird. Tatsächlich muss ich die alten Versionen von GCC aufgeben, die ich nicht allzu oft benutze, die aber nützlich sind, wenn ich sie brauche.

Oh, und ich habe ein Problem mit dem Konfigurationsskript für GNU Tar (1.28 und 1.26). Es wird getestet, wie tief ein Verzeichnisbaum erstellt werden kann, und es kann dann nicht aufgeräumt werden. Und wederrm Nochrmdir kann auch aufräumen, selbst wenn ichcd in der Hierarchie nach unten. Es wird der Fehler "Nicht genügend Speicherplatz" ausgegeben, obwohl noch viel Speicherplatz vorhanden ist. Ich kann Finder verwenden, um die Hierarchie in den Papierkorb zu verschieben. Finder kann sie aber auch nicht entfernen. Bash hat ein Tizzy, weil es nicht herausfinden kann, was das aktuelle Verzeichnis ist. Es ist alles irgendwie schmerzhaft! Das erneute Kompilieren und Installieren einiger Software-Komponenten ist daher nicht trivial. Ich kann sogar Dinge verwenden, die von anderen Leuten kompiliert wurden (MacPorts, HomeBrew usw.), aber ich mag es, meine eigenen zu kompilieren. Ich erhalte die Fehlermeldung "Der Vorgang kann nicht abgeschlossen werden, da der Eintrag" confdir-14B --- "verwendet wird". Ein Neustart ist möglicherweise in Ordnung, aber ich bin nicht sicher, ob das Problem dadurch behoben werden kann.