비트 코드를 사용한 재 컴파일 LC_ID_DYLIB

iOS 용 소스에서 비트 맵이 활성화 된 (cmake 및 xcodebuild 사용) 동적 프레임 워크를 구축하고 있습니다. 나는 바이너리를 올바르게로드하기 위해 lipo과 install_name_tool을 사용하여 팻 바이너리를 만들고 업데이트는 LC_ID_DYLIB입니다. 애플리케이션을 보관하면 프레임 워크가 애플리케이션에 올바르게 서명되고 패키지됩니다. 비트 코드를 사용한 재 컴파일 LC_ID_DYLIB

MyFramework: Mach-O universal binary with 3 architectures: [arm_v7: Mach-O dynamically linked shared library arm_v7] [arm_v7s] [arm64] 
MyFramework (for architecture armv7): Mach-O dynamically linked shared library arm_v7 
MyFramework (for architecture armv7s): Mach-O dynamically linked shared library arm_v7s 
MyFramework (for architecture arm64): Mach-O 64-bit dynamically linked shared library arm64

이 LC_ID_DYLIB에 대한 otool -l 출력을 보면이 보여줍니다 :이 file의 출력은

Load command 4 
      cmd LC_ID_DYLIB 
     cmdsize 64 
     name @rpath/MyFramework.framework/MyFramework (offset 24) 
    time stamp 1 Thu Jan 1 01:00:01 1970 
     current version 1.0.0 
compatibility version 1.0.0

그것은 모두가 올바른 것 같다. 이 보관소를 App Store에 업로드하면 올바르게 업로드되고 처리됩니다. App Store에서 실행 한 후에는 동적 프레임 워크로드로 인해 시작 직후에 충돌이 발생합니다. 앱 스토어의 Bitcode에서 앱을 다시 컴파일하는 것으로 알려져 있으므로 Ad-Hoc로 내보내고 "Bitcode에서 다시 빌드"옵션을 Technical Note TN2432에 제안 된대로 설정하면 시뮬레이트되었습니다. (또한 시작 후 충돌)을 .ipa 문제의 프레임 워크를 검사, 이것은 otool -l의 출력 : 위치에 분명히 그래서

Load command 3 
      cmd LC_ID_DYLIB 
     cmdsize 128 
     name /Users/legoless/Downloads/ios/build/build-iphoneos/lib/Release/MyFramework_ios.framework/MyFramework_ios (offset 24) 
    time stamp 1 Thu Jan 1 01:00:01 1970 
     current version 1.0.0 
compatibility version 1.0.0

이 라이브러리의 LC_ID_DYLIB 잘못이 절대 경로 곳 프레임 워크는 원래 굵은 이진 파일을 만들기 전에 만들어졌습니다. 이 코드는 비트 코드 단계에서 재구성되지만이 경로가 기존 Mach-O 파일에 저장되는 이유 또는 그 이유를 알지 못합니다. otool과 objdump 도구를 사용하여 Mach-O 바이너리의 참조를 찾으려고했습니다. 실제로

또 다른 프레임 워크는 이것에 따라이 대상 프레임 워크에 대한로드 명령입니다

Load command 14 
      cmd LC_LOAD_DYLIB 
     cmdsize 64 
     name @rpath/MyFramework.framework/MyFramework (offset 24) 
    time stamp 2 Thu Jan 1 01:00:02 1970 
     current version 1.0.0 
compatibility version 1.0.0

후 다시 비트 코드로 다시 작성 기준뿐만 아니라 여기 변경됩니다 :

Load command 13 
      cmd LC_LOAD_DYLIB 
     cmdsize 128 
     name /Users/legoless/Downloads/ios/build/build-iphoneos/lib/Release/MyFramework_ios.framework/MyFramework_ios (offset 24) 
    time stamp 2 Thu Jan 1 01:00:02 1970 
     current version 1.0.0 
compatibility version 1.0.0

이것은 문제의 프레임 워크에서만 발생하지만 @rpath은 그대로 남겨진 다른 프레임 워크에서는 발생하지 않습니다.

내 질문은 여전히 남아있다 :

어디이 절대 경로 참조가 저장되는? 그리고 그것을 제거하는 방법, 그래서 Bitcode에서 Rebuild는 더 이상 영향을 미치지 않습니까?

고맙습니다!

출처

2016-12-13 Legoless

Mach-O 파일 안에 비트 코드가 들어있는 .xar 아카이브는 링커 플래그를 포함하여 상당히 많은 정보를 저장함이 밝혀졌습니다. 이 정보는 목차에 저장되며 비트 코드 재 컴파일시 라이브러리를 다시 컴파일/다시 링크하는 데 사용됩니다. 내 경우

, 나는 링커 플래그에이 정보를 추가 cmake와 프레임 워크를 구축했다. INSTALL_NAME_DIR 및 BUILD_WITH_INSTALL_RPATH을 구성하고 @rpath를 사용하면 문제가 효과적으로 해결되었으며 install_name_tool은 더 이상 필요하지 않았습니다.

출처

2017-01-14 05:49:23 Legoless

정확히 동일한 문제가 발생했습니다. 허용 된 대답은 나에게 가까이 왔지만 INSTALL_NAME_DIR 매개 변수를 단독으로 설정해도 링커에 전달 된 전체 값을 install_name (예상 한대로 디렉토리 만)으로 설정할 수 없으므로 해결되지 않았습니다.

대신에 한 번에 전체 값을 덮어 쓰는 XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME을 설정합니다. 분명히 이것은 CMake의 XCode 생성기에서만 작동하지만, 내가 원했던 것은 괜찮았다. 요약하면,이 프레임 워크에 대한 내 CMake 파일은 다음을 포함합니다 :

출처

2017-09-21 10:48:00 mfj

비트 코드를 사용한 재 컴파일 LC_ID_DYLIB

답변

관련 문제