소프트웨어 개발자가 Linux에서 OS X로 전환할 때 직면하는 문제는 무엇입니까?

Question 1

나는 몇 년 전에도 같은 조치를 취했습니다. 내가 겪은 일은 다음과 같습니다.

일반 데스크톱 Linux는 OS X보다 사용자 공간이 더 풍부합니다.

내가 사용한 것과 다른 도구를 놓칠 수도 있으므로 대안 제안에 대해 구체적으로 설명할 필요는 없습니다.

대신에 그냥 설치하세요펑키 재즈,맥 포트, 또는스스로 만든첫 번째. 이러한 시스템은 Linux 또는 BSD의 일반적인 패키지 관리 시스템을 제공합니다. 각각 고유한 맛과 포장이 있으므로 귀하의 취향과 필요에 따라 올바른 선택이 달라집니다.

어떤 패키지 시스템도 필요한 모든 프로그램을 제공하지 않을 수 있습니다. 일부 프로그램은 OS X로 포팅되지 않았으므로 다음 버전에 나타나지 않습니다.어느패키지 시스템. 그럼에도 불구하고 이러한 시스템은 OS X와 함께 제공되는 기능을 크게 확장하며 Linux에서 쉽게 전환할 수 있습니다.

이제 OS X 명령줄 컴파일러는 기본적으로 64비트 실행 파일을 빌드합니다.

Leopard 및 이전 버전에서는 컴파일러가 기본적으로 32비트 실행 파일을 빌드했습니다. 이로 인해 여러 가지 방법으로 문제가 발생할 수 있습니다. 다시 빌드할 수 없지만 연결해야 하는 오래된 32비트 라이브러리가 있을 수 있으며, 시스템을 여전히 32비트 모드에서 실행 중일 수 있습니다.

32비트 빌드를 강제하는 한 가지 방법은 gcc빌드 시스템에서 gcc-4.0이전 기본 32비트 Leopard 컴파일러인 기본값 재정의를 사용하는 것입니다. ( gcc이것은 Snow Leopard의 기본 64비트 심볼릭 링크입니다 gcc-4.2.) 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 Dee Boer)가 썼다.이에 대한 좋은 기사, 자세한 내용은 다음과 같습니다.

동적 링크 + 타사 패키지는 초기 단계에서 두통을 유발할 수 있습니다.

라이브러리를 표준 위치에 설치하지 않는 타사 패키지의 라이브러리를 사용하려고 시도하면 초기에 동적 연결 문제가 발생할 가능성이 높습니다.맥 포트예를 들어, 또는 /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 호환성 문제를 처리합니다.

64비트 Linux에서는 32비트를 지원해야 하는 이유가 무엇이든 두 가지 형식이 모두 필요한 라이브러리와 같은 두 개의 복사본이 생성되고 64비트 버전은 lib64기존 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'

PowerPC 지원이 필요하면 및 -arch ppc -arch ppc64에 추가하세요 CFLAGS.LDFLAGS

.o종속성 추적을 비활성화하지 않으면 첫 번째 플랫폼에 대한 새 파일이 있다는 것은 make(1)두 번째 플랫폼에 대해서도 빌드할 필요가 없음을 나타내기 때문에 하나의 플랫폼에 대해서만 빌드하게 됩니다. 위의 예에서는 모든 것을 두 번 빌드해야 합니다. 여전히 PowerPC 지원이 필요한 경우 완전한 범용 바이너리의 경우 네 번 빌드해야 합니다.

(자세한 내용은Apple 기술 노트 TN2137.)

기본적으로 개발자 도구는 OS X에 설치되지 않습니다.

Lion 이전에는 시스템에 적합한 개발 도구를 얻을 수 있는 가장 신뢰할 수 있는 곳은 운영 체제 CD였습니다. 선택적 설치입니다.

운영 체제 CD에서 개발 도구를 설치하면 도구가 운영 체제와 함께 사용된다는 것을 알 수 있다는 이점이 있습니다. Apple은 Apple이므로 최신 컴파일러를 실행하려면 최신 버전의 OS가 있어야 하며, 항상 이전 도구의 다운로드를 제공하는 것은 아니므로 OS CD는 일반적으로 주어진 환경에 적합한 도구를 찾는 가장 쉬운 방법입니다. . 개발 또는 테스트 상자.

Lion에서는 설치 미디어를 없애려고 했기 때문에 값비싼 USB 키 버전을 구입하지 않는 한App Store에서 Xcode 다운로드.

다운로드하는 Xcode DMG의 최소 몇 가지 버전을 유지하는 것이 좋습니다. Lion의 후속 제품이 1~3년 후에 출시되면 Lion 테스트 VM에 동시 버전의 Xcode를 설치할 수 없다는 사실을 알게 될 수도 있습니다. 가용성 문제와 운영 체제 미디어 부족으로 인해 이전 버전의 Xcode를 얻을 수 없는 경우를 대비하여 미리 계획하세요.

Answer