sourcecode

Xcode에서 "Linked Frameworks"가 아닌 "내장 바이너리"를 사용해야 하는 경우는 언제입니까?

copyscript 2023. 4. 29. 09:48
반응형

Xcode에서 "Linked Frameworks"가 아닌 "내장 바이너리"를 사용해야 하는 경우는 언제입니까?

라이브러리 VS 임베디드 프레임워크를 사용한 링크 바이너리에 설명된 두 옵션의 차이에 대한 좋은 질문이 있습니다.

둘 다 사용할 수 있는 옵션이 있는 것 같습니다. 링크된 프레임워크보다 임베디드 바이너리를 더 잘 사용해야 하는 경우가 있는지 궁금합니다.

이 문제를 좀 더 명확하게 해결할 수 있는 확실한 예가 있습니까?감사해요.

링크한 질문은 "라이브러리와 이진 연결" 기능을 참조하며, 이 기능은 내장된 이진과 다소 다릅니다.

"라이브러리와 이진 연결"은 링크와 관련하여 예상되는 것을 의미합니다.바이너리가 정적 라이브러리, 동적 라이브러리 또는 프레임워크인지 여부에 관계없이 컴파일 후 링크 시 개체 코드에 연결됩니다.

정적 라이브러리와의 연결을 생각할 때, 링크어는 라이브러리에서 코드를 복사합니다.libFoo.a출력 바이너리에 합니다.을 출력 바이너리에 입력합니다.출력 파일의 크기는 커지지만 런타임에 외부 종속성을 해결할 필요는 없습니다.정적 라이브러리와 관련하여 프로그램을 실행하는 데 필요한 모든 것이 빌드된 후에 나타납니다.

동적 라이브러리(.dylib 또는 시스템 제공 프레임워크)를 사용할 경우 프로그램을 실행할 때 링크 대상 라이브러리가 시스템의 동적 라이브러리 로더 경로 어딘가에 있어야 합니다.이렇게 하면 모든 타사 외부 라이브러리를 이진 파일로 복사하는 오버헤드가 발생하지 않고 해당 라이브러리에 연결된 컴퓨터의 모든 다른 프로그램에서 해당 라이브러리를 찾을 수 있으므로 시스템이 라이브러리를 캐시하는 방법과 위치에 따라 디스크 공간은 최소화할 뿐만 아니라 잠재적으로 메모리 공간도 절약할 수 있습니다.

프레임워크는 동적 라이브러리와 비슷하지만 디렉토리 구조(이미지, 오디오, 기타 프레임워크 등)에 리소스를 포함할 수 있습니다.이 경우 단순한 정적 라이브러리 또는 .dylib 파일은 이 파일을 잘라내지 않으므로 제대로 실행해야 할 항목을 찾기 위해 프레임워크에 연결해야 할 수도 있습니다.

타사 프레임워크에 연결할 때(예: github에서 다운로드하여 직접 만든 프레임워크) 실행하려는 시스템에 해당 프레임워크가 없을 수 있습니다.이 경우 프레임워크에 링크할 뿐만 아니라 "프레임워크 복사" 단계를 사용하여 애플리케이션 번들에 포함시킬 수 있습니다.프로그램이 실행되면 런타임 링커(해결 프로그램이라고도 함)가 시스템 로더 경로 외에도 번들 내부를 살펴보고 내장된 프레임워크를 찾은 다음 이를 연결하여 앱이 실행되는 데 필요한 코드를 갖게 됩니다.

" 바이너리 단계를 "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "popen()또는 그와 유사합니다.프로그램에서 내장된 이진 파일을 호출할 수 있지만 연결되어 있지 않습니다.(의 프로그램과 같이) 완전히 외부 엔티티입니다./bin디렉토리)를 선택합니다.

실제로 시스템에서 제공하는 라이브러리 및 프레임워크에 대해 링크를 연결하면 됩니다.

내장된 리소스가 필요 없는 라이브러리(즉, 프레임워크가 필요하지 않음)를 연결해야 하는 경우에는 정적 라이브러리에 연결하기만 하면 됩니다.프로그램에 동일한 라이브러리 코드를 사용하려는 모듈이 여러 개 있는 경우 이를 프레임워크 또는 동적 라이브러리로 변환하고 이에 대한 링크를 통해 공간을 절약할 수 있고 편리할 수 있습니다(특히 메모리 사용이 문제인 경우).

마지막으로, 프레임워크는 리소스뿐만 아니라 헤더 및/또는 라이센스 파일도 포함할 수 있습니다.이러한 파일을 전달하기 위해 프레임워크를 사용하는 것은 실제로 편리한 배포 메커니즘이므로 종종 이러한 파일을 바이너리와 함께 태그할 수 있도록 프레임워크를 통합하고 싶을 수 있습니다(즉, 라이센스 요구사항으로 인해 필수가 될 수 있음).

편집 ---

Adam Johns는 다음과 같은 질문을 댓글로 올렸습니다.

이것은 훌륭한 대답입니다.하지만 아직도 약간 혼란스러운 점이 있습니다.바이너리를 직접 실행한다는 것은 무엇을 의미합니까?단순히 임베디드 프레임워크의 코드를 사용하는 것을 의미합니까?당신이 popen()을 언급한 것은 알지만, 제 앱이 popen()을 부른다는 건가요?그게 무슨 뜻인지 잘 모르겠어요.

제 말은 임베디드 바이너리는 오디오 파일이나 이미지와 같은 번들의 또 다른 리소스 파일에 불과하지만 파일은 대신 실행 가능한 명령줄 도구라는 것입니다.popen()함수)man popen터미널에서 터미널에 대한 자세한 내용을 참조)를 사용하여 실행 중인 다른 프로그램에서 임의 프로그램을 실행할 수 있습니다.system()기능은 또 다른 방법입니다.다른 예를 들어, 내장된 바이너리를 좀 더 명확하게 이해할 수 있는 역사적인 예를 들어보겠습니다.

아시다시피 Mac OS X에서 앱을 실행하면 현재 사용자의 사용자 ID로 실행됩니다.은 다음과 .admin ID 사자, 사가 ID 지된이 501.

에만 사용할 수 .root ID user(사용자 ID)0)는 전체 파일 시스템에 대한 전체 액세스 권한을 가집니다.데스크톱 사용자가 시작한 설치 프로그램이 권한 있는 디렉터리(예: 드라이버)에 파일을 설치해야 하는 경우가 있습니다.▁the로 권한을 확대해야 합니다.root사용자가 제한된 디렉토리에 쓸 수 있도록 합니다.

OS X 10.7을 통해 운영 체제에서 이를 용이하게 하기 위해 Apple은 Authorization Services API에서 Authorization 기능을 제공했습니다.ExecuteWithPrivileges()(이것은 현재는 더 이상 사용되지 않지만 여전히 유용한 예입니다.)

AuthorizationExecuteWithPrivileges()하여 명령행 도구로 했습니다.root명령줄 도구는 설치 논리를 실행하기 위해 작성한 실행 가능한 셸 스크립트 또는 컴파일된 이진 파일입니다.이 도구는 다른 리소스 파일과 마찬가지로 응용프로그램 번들 내에 설치되었습니다.

(에 본 적이 합니다.root당신의 앱을 대신해서.을 실행하는 것과 유사합니다.popen(), 비록 자신신만하지, 당만,,.popen()단독으로는 권한 상승의 혜택을 받지 못합니다.

요컨대,

  • 시스템 라이브러리, 링크
  • 타사 라이브러리를 포함합니다.

왜요?

  • 시스템 라이브러리를 포함하려고 하면 팝업 목록에서 찾을 수 없습니다.
  • 타사 라이브러리를 연결하면 충돌이 발생할 수 있습니다.

Xcode v11 이전 버전.포함된 이진 대 연결된 프레임워크 및 라이브러리

역사

Embedded Binaries vs Linked Frameworks and Libraries -> Frameworks, Libraries, and Embedded Content

[Xcode v11. Frameworks, Libraries 및 Embedded Content]에서 Xcode v11 섹션으로 대체되었습니다.General

embedded binaries그리고.Linked FrameworksDependency경영진

[Xcode v11]

링크 이진

General -> Linked Frameworks and Libraries는 의거니다입의 입니다.Build Phases -> Link Binary With Libraries.

정적 라이브러리 및 프레임워크

을 하면,Static Library or Static Framework에는 이섹에표니다됩시에 됩니다.Frameworks 그룹[정보](Project Navigator -> <workspace/project> -> Frameworks프로젝트에 대한 참조가 추가됩니다.그러면 다음 사용자가 사용합니다.Static Linker.Static Linker컴파일 시 라이브러리의 모든 코드를 실행 개체 파일에 포함/복사합니다. Static linker과 짝을 지어 Build Settings -> <Library/Framework> Search Paths

Static Library

Static Framework

  • Build Settings -> Framework Search Paths 당신이 를 추가하지 .static framework이 섹션으로 컴파일[해당 모듈 없음] 오류가 발생합니다.

이진 포함

정적 라이브러리 및 정적 프레임워크

임베딩은 의미가 없습니다.Static Library그리고.Static Framework왜냐하면 그들의 기호들이 실행 가능한 바이너리로 컴파일되기 때문입니다.Xcode는 당신이 a를 떨어뜨리지 못하게 할 것입니다.static libraryEmbed 섹션 아래에 있습니다.

동적 프레임워크

General -> Embedded Binaries는 의거니다입의 입니다.Build Phases -> Embed Frameworks.

임베딩은 실제로 프레임워크의 복사본을 애플리케이션 번들에 추가합니다(프레임워크와 애플리케이션의 코드를 단일 실행 가능 바이너리로 병합하지 않음).

는 기적으번폴더입니다.Frameworks하지만 사용하여 변경할 수 있습니다.Destination 드를 할 수 . 또한 다음을 지정할 수 있습니다.Subpath.

Dynamic linker :dyld로드 또는 런타임에서 다음을 사용하여 내장된 프레임워크를 찾으려고 합니다.@rpath[정보] 찾을 수 없으면 오류가 발생합니다.

결과:

  • Static Library-Link
  • Static Framework-Link
  • Dynamic Framework-Embed

[정적 링커 vs 동적 링커]
[링크 및 임베드 사용 시]
[어휘]

언급URL : https://stackoverflow.com/questions/32675272/when-should-we-use-embedded-binaries-rather-than-linked-frameworks-in-xcode

반응형