저는 로컬로 빌드 된 stack 프로젝트를 사용하여 lib_.so을 El Capitan의 공유 lib 디렉토리에 복사합니다. 이 공유 객체는 그 자체가 다수의 다른 사람들과 연결되어 있으며, 모두 .so 파일입니다. 다른 stack 프로젝트가 로컬 종속성으로 첫 번째 프로젝트를 참조하고 해당 스택이 lib_.dylib을 공유 디렉토리에서 찾지 만 lib_.so이 아닌 것을 제외하고는 해당 디렉토리로 복사하는 공유 라이브러리를 찾을 것으로 예상됩니다. 그것은 파일을 찾지 못할 가능성이 있습니다.강제로 스택이 OS X에서 .dylib 대신 .so 파일을 찾으십니까?
파일에 .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 또는 accepting ;-) 고려하십시오. – Blaisorblade
내가 이해하지 못하는 몇 가지 연결 문제로 인해 모든 이름이 변경되지 않았습니다. 결국 관리자는 OSX에서'.so'와'.dylib' 파일을 생성하도록 빌드 스크립트를 변경했습니다. 이 문제가 해결되었습니다. – user2805751
스택 bugtracker에서 제공됩니다. OS X의 공유 라이브러리는'.so'가 아닌'.dylib '확장자를 가지고 있으므로 그렇게 할 방법이 없다고 생각합니다. 저는 이것이 GHC에 의해 시행된다고 가정합니다. 첫 번째 질문은 OS X에'.so' 파일을 설치하는 이유는 무엇입니까? 그런 다음,'.so'가 하스켈 라이브러리 인 경우 이것은 잘못된 설정입니다. 다른 라이브러리라면 이식성이없는 빌드 스크립트 만 있습니다. – Blaisorblade
부분 철회 : http://stackoverflow.com/a/2339910/53974는 '로드 가능한 모듈/번들 *'에 대해 '.so'가 일반적이지만 (비표준) 링크 할 수 없다고 제안합니다. 런타임에로드되어야 함). 그러나 다시 말하면 "번들이 공유 라이브러리 인 것처럼 번들에 연결할 수 없습니다." 따라서 * 만약 그렇다면, 당신이하려는 일은 당신의 일이 아니더라도 작동하지 않아야합니다. – Blaisorblade