몇 년 전 같은 움직임을 보였습니다. 내가 겪은 것들은 다음과 같습니다.
일반적인 데스크탑 리눅스는 OS X보다 풍부한 사용자 영역을 가지고 있습니다.
당신은 아마 내가했던 것과 다른 도구를 그리워 할 것이므로 교체 권장 사항에 대해 구체적으로 말하지 마십시오.
대신 Fink , MacPorts 또는 Homebrew를 먼저 설치하십시오 . 이 시스템은 일반적인 Linux 또는 BSD 패키지 관리 시스템을 제공합니다. 각각 고유 한 맛과 패키지 세트가 있으므로 취향과 필요에 따라 올바른 선택이 가능합니다.
하나의 패키지 시스템에 필요한 모든 프로그램이있는 것은 아닙니다. 일부 프로그램은 아직 OS X로 포팅되지 않았으므로 어떤 패키지 시스템 에도 나타나지 않습니다 . 그럼에도 불구하고,이 시스템은 OS X와 함께 제공되는 것을 크게 확장하고 Linux에서 쉽게 전환 할 수 있습니다.
OS X 명령 행 컴파일러는 이제 기본적으로 64 비트 실행 파일을 빌드합니다.
Leopard 및 이전 버전에서 컴파일러는 기본적으로 32 비트 실행 파일을 빌드했습니다. 여러 가지 방법으로 문제가 발생할 수 있습니다. 다시 빌드 할 수 없지만 링크해야하는 오래된 32 비트 라이브러리가 있거나 32 비트 모드로 시스템을 계속 실행 중일 수 있습니다.
32 비트 빌드를 강제 실행하는 한 가지 방법 gcc은 빌드 시스템에서 기본값을 gcc-4.0이전 32 비트 레오파드 컴파일러로 사용하여 기본값 을 대체 하는 것입니다. ( Snow Leopard에서 gcc기본적 gcc-4.2으로 64 비트에 대한 심볼릭 링크 입니다.) autoconf 기반 빌드 시스템에서는 다음과 같이 작동합니다.
$ ./configure CC=gcc-4.0 CXX=g++-4.0
( CXX프로그램에 C ++ 구성 요소가 포함 된 경우 에만 비트 가 필요합니다 .)
또 다른 방법은 -m32컴파일러와 링커 에 전달 하는 것입니다 .
$ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
더 타이핑하지만 최신 GCC에서 32 비트 빌드를 얻을 수 있습니다.
동적 연결은 크게 다릅니다.
ld손으로 명령 을 작성하는 사람이라면 그 습관을 깰 때입니다. 대신 컴파일러를 통해 또는 같은 중개자를 사용하여 프로그램과 라이브러리를 연결해야합니다 libtool. 이들은 플랫폼 별 링크 구조의 차이를 처리하므로 휴대용 메커니즘으로 추상화 할 수없는 학습 프로그램의 두뇌 능력을 절약 할 수 있습니다.
예를 들어, 어떤 라이브러리 가 연결되어 있는지 파악하는 otool -L someprogram대신 입력하여 근육 메모리를 업데이트해야 합니다.ldd someprogramsomeprogram
처음에는 두뇌를 왜곡시키는 동적 연결의 또 다른 차이점은 OS X에서 라이브러리의 설치 위치 가 라이브러리 자체에 기록 되고 링커가 링크 타임에 실행 파일에 복사한다는 것입니다. 즉, 설치된 라이브러리에 링크 /usr/local/lib했지만 실행 파일과 동일한 디렉토리에있는 사용자에게 라이브러리를 제공 하려면 설치 프로세스의 일부로 다음과 같이 말해야합니다.
$ cp /usr/local/lib/libfoo.dylib .
$ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
$ make LDFLAGS=-L. relink
이제 위의 많은 부분이 빌드 시스템에 따라 다를 수 있으므로 레시피가 아닌 예제로 사용하십시오. 이것이하는 일은 우리가 링크하는 라이브러리의 개인 복사본을 만들고 공유 라이브러리 식별자를 절대 경로에서 "실행 파일과 같은 디렉토리에있는"을 의미하는 상대 경로로 변경 한 다음이 수정 된 복사본에 대해 실행 파일을 강제로 다시 작성하는 것입니다 도서관의.
install_name_tool여기서 핵심 명령입니다. 대신 ../lib실행 파일과 관련된 디렉토리에 라이브러리를 설치하려면 -id인수가 @loader_path/../lib/libfoo.dylib대신 필요합니다 .
Joe Di Pol은 이것에 대해 더 자세한 내용 으로 좋은 기사를 썼습니다 .
동적 연결 + 타사 패키지는 초기에 두통을 유발할 수 있습니다.
라이브러리를 표준 위치에 설치하지 않은 타사 패키지의 라이브러리를 사용하려고 시도하는 즉시 동적 연결 문제가 발생할 수 있습니다. 예를 들어, MacPorts 는 또는 /opt/local/lib대신 라이브러리를 라이브러리에 설치 합니다. 이 문제가 발생하면 다음과 같은 줄을 다음과 같이 추가하십시오 ./usr/lib/usr/local/lib.bash_profile
# Tell the dynamic linker (dyld) where to find MacPorts package libs
export DYLD_LIBRARY_PATH=/opt/local/lib:$DYLD_LIBRARY_PATH
# Add MacPorts header file install dirs to your gcc and g++ include paths
export C_INCLUDE_PATH=/opt/local/include:$C_INCLUDE_PATH
export CPLUS_INCLUDE_PATH=/opt/local/include:$CPLUS_INCLUDE_PATH
OS X은 Linux와 다르게 CPU 호환성 문제를 처리합니다.
어떤 이유로 든 32 비트를 지원해야하는 64 비트 Linux에서는 64 비트 버전의 lib64디렉토리와 동일한 디렉토리 에서 64 비트 버전을 사용하지 않고 두 가지 형식으로되어 있어야하는 라이브러리와 같은 두 개의 사본으로 끝납니다 . 전통적인 lib디렉토리.
OS X은 여러 바이너리를 단일 파일에 넣을 수있는 범용 바이너리 개념으로이 문제를 다르게 해결합니다. 현재 최대 4 개의 CPU 유형 (32 비트 및 64 비트 PowerPC, 32 비트 및 64 비트 Intel)을 지원하는 실행 파일이있을 수 있습니다.
Xcode를 사용하여 범용 바이너리를 쉽게 만들 수 있지만 명령 줄 도구를 사용하면 약간의 어려움이 있습니다. 이를 통해 Autoconf 기반 빌드 시스템을 갖춘 범용 Intel 전용 빌드를 얻을 수 있습니다.
$ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
LDFLAGS='-arch i386 -arch x86_64'
추가 -arch ppc -arch ppc64받는 사람 CFLAGS과 LDFLAGS당신은 파워 지원이 필요합니다.
종속성 추적을 비활성화하지 않으면 .o첫 번째 플랫폼에 대해 새로 작성된 파일 이 존재 make(1)하므로 두 번째 플랫폼에 대해서도 빌드 할 필요가 없기 때문에 하나의 플랫폼에 대해서만 빌드하게됩니다. 위 예제에서 모든 것을 두 번 빌드해야합니다. 여전히 PowerPC 지원이 필요한 경우 완전 범용 바이너리의 경우 네 번.
( Apple 기술 노트 TN2137 에 자세한 정보가 있습니다.)
개발자 도구는 기본적으로 OS X에 설치되어 있지 않습니다.
Lion 이전에는 시스템에 적합한 개발 도구를 얻을 수있는 가장 안정적인 장소는 OS 디스크였습니다. 그들은 선택적 설치입니다.
OS 디스크에서 개발 도구를 설치할 때 좋은 점은 도구가 OS에서 작동한다는 것을 알고 있다는 것입니다. Apple은 Apple이기 때문에 최신 컴파일러를 실행하려면 최신 버전의 OS가 있어야하며 이전 도구를 항상 다운로드 할 수있는 것은 아니므로 OS 디스크는 종종 주어진 도구에 적합한 도구를 찾는 가장 쉬운 방법입니다 개발자 또는 테스트 상자.
Lion은 설치 미디어를 없애려고 노력하기 때문에 비싼 USB 키 버전을 구입하지 않으면 App Store에서 Xcode 를 다운로드 해야합니다 .
다운로드 한 Xcode DMG의 버전을 최소한 몇 개는 유지하는 것이 좋습니다. Lion의 후임자가 1 년에서 3 년 후에 나올 때 Lion Test VM에 동시 버전의 Xcode를 설치할 수있는 방법없이 자신을 발견 할 수 있습니다. 가용성 문제와 OS 미디어 부족으로 인해 이전 버전의 Xcode를 얻을 수없는 경우 미리 계획하십시오.