问题描述
自远古时代以来(无论如何，在上个世纪的某个地方)，我创建了诸如/usr/gnu和/usr/gcc之类的目录来存放自定义编译的GNU软件，与系统目录中的任何内容分开.自2002年以来(Jaguar，10.2)，它在包括Mac OS X在内的各种基于Unix的系统上都非常有效. (不使用/usr/local的一个原因是IT管理层对其进行了维护，并且始终包含过时的代码-例如，直到大约5年前，Perl 4才可用.使用其他名称避免了它们的运行.)
Since time immemorial (somewhere in the previous millennium, anyway), I've created directories such as /usr/gnu and /usr/gcc to hold custom-compiled GNU software, separate from anything in the system directories. This has worked well for me, on a wide variety of Unix-based systems, including Mac OS X since 2002 (Jaguar, 10.2). (One reason for not using /usr/local was that the IT management maintained it, and it always contained archaic code — it had Perl 4 available until about 5 years ago, for example. Using other names avoided run-ins with them.)
在Mac OS X 10.11 El Capitan中，苹果推出了SIP(系统完整性保护)系统(在问不同".这意味着我无法再创建/usr/gnu或/usr/gcc之类的目录，即使它们与Apple所拥有的任何内容都不相干.
With Mac OS X 10.11 El Capitan, Apple has introduced the SIP (System Integrity Protection) system (described at What is the "rootless" feature of El Capitan, really? on 'Ask Different'). It means that I can no longer create directories such as /usr/gnu or /usr/gcc, even though they're disjoint from anything that Apple has.
我发现以前这些目录中的软件已在这些目录中隔离(其中UUID在您的计算机上会有所不同，并且我可能有两个，因为将El Capitan安装到此计算机上是多步操作-分开的漫长而无聊的故事):
I found that the software previously in those directories had been quarantined in directories like these (where the UUIDs will be different on your machine, and I probably have two because getting El Capitan onto this machine was a multi-step operation — a separate long and boring story):
$ ls -1 /Library/SystemMigration/History/
Migration-7D74B534-AA54-4A4A-8DCC-A5C2F28E1A39
Migration-9C0FE7A4-3445-4BD6-A512-35464EECCBC3
$
，然后在QuarantineRoot下的子目录中:
and then in sub-directories under QuarantineRoot:
$ ls /Library/SystemMigration/History/Migration-9C0FE7A4-3445-4BD6-A512-35464EECCBC3/QuarantineRoot/usr:
gcc gnu32 gnu64
$
但是，这些二进制文件是使用GCC和各种库编译的，因此它们目前无法运行.例如:
However, the binaries were compiled with GCC and various libraries, so they don't run at the moment. For example:
$ 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，我什至不能在/usr中创建符号链接，以使gcc或gnu64指向其他位置(甚至不能以root特权运行).这是我用来在Machinea上创建具有/work1备用空间的软件的技术之一，该技术可以在另一台具有/work5剩余空间的MachineB上使用. /usr中的符号链接允许代码位于/work1/gcc或/work5/gcc中，并且只要/usr/gcc指向文件的实际安装位置，它就可以正常工作.因此，这个SIP系统似乎杀死了几十年来成功使用的所有机制，这些机制基于能够在/usr中创建至少某种目录条目.
AFAIK, I can't even create symlinks in /usr such that gcc or gnu64 points somewhere else (not even running with root privileges). That's one of the techniques I've used to create software on MachineA with spare space in /work1 for use on another MachineB with spare space in /work5; a symlink in /usr allows the code to sit in /work1/gcc or /work5/gcc and it works correctly as long as /usr/gcc points to where the files are actually installed. So, this SIP system seems to kill all the mechanisms used successfully for a couple of decades which are predicated on being able to create at least some sort of directory entry in /usr.
- 是否有一种明智的方法来使旧的二进制文件在不禁用SIP且无需立即重新编译所有内容的情况下运行 ?
后备位置是重新编译软件-避免将/usr作为安装位置".随着时间的推移，我计划使用/opt/gcc和/opt/gnu64而不是/usr下的等效项.我什至正在考虑在主目录下使用空间，即使我不想这样做.它是系统"软件.
The fall-back position is "recompile the software — avoiding /usr as an install location". Over time, I plan to use /opt/gcc and /opt/gnu64 instead of the equivalents under /usr. I'm even contemplating using space under my home directory, even though I'd rather not; it is 'system' software.
但是，我已经编译了很多软件，其中包括GCC的多个版本(从4.4.2到5.2.0)，这将很麻烦地进行重新编译.实际上，我将不得不放弃旧版本的GCC，我不会经常使用所有旧版本的GCC，但是当我确实需要它们时，它们会很有用.
However, I have quite a lot of software already compiled, including multiple versions of GCC (from 4.4.2 through 5.2.0), which it will be a nuisance to recompile. In fact, I'll have to abandon the old versions of GCC, which I don't use all that often, but which are useful when I do need them.
推荐答案
仅出于关闭目的:
- 否；似乎没有办法避免重新编译代码.
如果您想访问聊天链接，请务必这样做，但最终得出的结论是相同的.
If you want to follow the chat link, by all means do so, but it ends up at the same conclusion.
这篇关于Mac OS X El Capitan可以运行为优胜美地编译的，需要/usr/gnu64/lib中的库的软件吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！