我有一个本地构建的stack项目，它将lib_.so复制到El Capitan的共享lib目录中。这个共享对象本身与其他许多链接，所有这些文件都是.so文件。我有另一个stack项目将第一个项目引用为本地依赖项，并期望找到它复制到所述目录的共享库，但堆栈在共享目录中查找lib_.dylib而不是lib_.so。它有可能无法找到该文件。强制堆栈在OS X上查找.so文件而不是.dylib？
有没有办法告诉堆栈它应该使用.so文件？如果我将根文件重命名为.dylib堆栈可以找到它，但无法找到其他链接的文件，所有这些文件预计为.dylib。
如果我将根文件重命名为.dylib堆栈可以找到它，但却无法找到其他链接文件，所有这些文件都应该是.dylib。
我建议重命名所有的库进行.dylib，即使用https://stackoverflow.com/a/14887391/53974或许https://www.tekrevue.com/tip/batch-rename-files-os-x-yosemite/或其他谷歌的结果。我不知道它是否可行，因为它取决于生成这些库的构建脚本的错误方式，但是您的结果表明构建脚本可能只是对共享库使用了错误的扩展。
感谢您的回复：“可能只是对共享库使用了错误的扩展名。”可能是罪魁祸首，虽然它不是我的包，它不是一个简单的包。我会看看是否重命名他们所有的人都会得到快乐。 – user2805751
我想象中。请考虑upvoting或接受;-)。 – Blaisorblade
更改所有名称不起作用，因为一些链接的怪癖，我不明白。最后，维护人员改变了构建脚本在OSX上生成'.so'和'.dylib'文件。这固定了它。 – user2805751
来自Stack bugtracker。 OS X上的共享库具有'.dylib'扩展名，而不是'.so'，所以我猜想没有办法做到这一点。我认为这是由GHC执行的。所以第一个问题是，为什么你要在OS X上安装'.so'文件？然后，如果'.so'是一个Haskell库，这是一个糟糕的设置，如果它是任何其他库，它只是一个不可移植的构建脚本。 – Blaisorblade
部分回收：http://stackoverflow.com/a/2339910/53974表明'.so'对于*可加载模块/捆绑*是常见的（但非标准的），你不能链接（它们是应该在运行时加载）。 但是，“不可能像捆绑一样链接到共享库。”所以，如果*就是这种情况，那么你试图做的事情不应该起作用，尽管这可能不是你的事。 – Blaisorblade