Mac OS X El Capitan是否可以运行为约塞米蒂编译的软件，该软件需要/usr/gnu64/lib中的库？

抱歉，需要一些背景知识-您可以尝试跳到问题标题

自古以来（无论如何，在上一个千年的某个地方），我创建了目录，如

/usr/gnu

和

/usr/gcc

，以保存自定义编译的gnu软件，与系统目录中的任何内容分开。这对我来说非常有效，在各种基于Unix的系统上，包括2002年以来的MacOSX（Jaguar，10.2）。（不使用

/usr/local

的一个原因是IT管理层维护了它，而且它总是包含过时的代码——例如，直到大约5年前它才有Perl 4可用。使用其他名称可以避免与它们发生冲突。）

通过Mac OS X 10.11 El Capitan，苹果推出了SIP（系统完整性保护）系统（在“询问不同”一节中介绍）。这意味着我不能再创建诸如

/usr/gnu

或

/usr/gcc

之类的目录，即使它们与苹果的任何目录都是不相交的

我发现以前那些目录中的软件被隔离在这样的目录中（UUID在您的机器上会有所不同，我可能有两个，因为让El Capitan进入这台机器是一个多步骤的操作-一个单独的冗长乏味的故事）：

然后在

QuarantineRoot

下的子目录中：

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

然而，二进制文件是用GCC和各种库编译的，所以它们目前不运行。例如：

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

好吧，我甚至不能在

/usr

中创建符号链接，这样

gcc

或

gnu64

就指向其他地方（甚至不能以root权限运行）。这是我用来在机器上创建软件的技术之一，在

/work1

中有空闲空间，可在另一台机器上使用

/work5

中有空闲空间；

/usr

中的符号链接允许代码位于

/work1/gcc

或

/work5/gcc

中，只要

/usr/gcc

指向文件的实际安装位置，它就可以正常工作。因此，这个SIP系统似乎扼杀了几十年来成功使用的所有机制，这些机制的前提是能够在

/usr

中创建至少某种目录条目

问题:

• 有没有一种合理的方法可以让旧的二进制文件在不禁用SIP和不需要立即重新编译所有内容的情况下运行

后退位置是“重新编译软件-避免将

/usr

作为安装位置”。随着时间的推移，我计划使用

/opt/gcc

和

/opt/gnu64

而不是

/usr

下的等价物。我甚至在考虑使用我的主目录下的空间，尽管我不愿意；它是“系统”软件

然而，我已经编译了很多软件，包括GCC的多个版本（从4.4.2到5.2.0），重新编译会很麻烦。事实上，我将不得不放弃GCC的旧版本，我并不经常使用它，但当我确实需要它们时，它是有用的

---

---

哦，我对GNUtar（1.28和1.26）的配置脚本有一个问题。它测试它可以创建多深的目录树，然后无法清理。而且无论是

rm

还是

rmdir

都不能清除，即使我

cd

从层次结构到底部。它会出现“磁盘空间不足”错误，即使还有很多空间。我可以使用Finder将层次结构移动到垃圾箱。但是Finder也不能删除它们。Bash有一个问题，因为它无法计算出当前目录是什么。这一切都有点痛苦！因此，重新编译和重新安装一些软件并不是件小事。我甚至可能会使用其他人编译的东西（MacPorts、HomeBrew等），但我喜欢自己编译。我得到错误“操作无法完成，因为项目“confdir-14B---”正在使用”；重新启动可能是正确的，但我不相信它会解决这个问题。

只是为了结束：

• 没有；似乎没有办法避免重新编译代码

---

如果你想关注聊天链接，一定要这么做，但结果都是一样的。

一个风滚草徽章之后（这不是一开始的意图），我准备假设答案是“不，没有一种方法可以合理地解决这个问题”，所以整套重建工作已经就绪。tar问题已报告给GNU tar维护者；有一个行动项目回复我，我还没有采取必要的措施。（我不相信这会是在主题上-我在询问之前查看了这里，它似乎被明确地从他们的主题项目列表中排除。）我只是偶然发现，这可能提供了一条解决此问题的途径。我还没有对它进行测试，但它似乎暂时使用了

csrutil disable

来允许创建新目录，更改该目录上的权限以允许“无根”访问，然后重新启用SIP。如果没有其他人先做，我会在自己测试后再给出一个真实的答案。@GrahamKlyne:谢谢你的链接。这并不能解决我的问题，那就是我的软件配置为生活在

/usr/gnu64

和

/usr/gcc

下。我的

/usr/local

没有问题，只是我的软件没有使用它-目录存在正常，并且具有可接受的权限，我的想法是，您可以使用所描述的过程创建可访问的目录

/usr/gnu64

和

/usr/gcc

，然后像以前一样继续。但我可能还是遗漏了一些东西。您是否尝试过使用DYLD\u LIBRARY\u PATH环境变量？你可以跑你的职业选手

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