multilib-build.eclass젠투에서 -style multilib를 사용한 경험이 거의 없다는 것을 공개해야합니다 .
ABI_X86A는 USE_EXPAND변수; 설정 ABI_X86="32 64"또는 USE="abi_x86_32 abi_x86_64"동일합니다. 이 글을 쓰는 시점 (2013-09-09)의 default/linux/amd64/13.0프로필에 대한 ABI_X86의 기본 설정은 그냥 ABI_X86=64입니다.
이 변수는 ebuild에서 명시적인 multilib 지원을 제어합니다.이 빌드 multilib-build.eclass는 원래 방법보다 multilib를 수행하는 젠투와 유사한 방법입니다.
32 비트 라이브러리가 젠투에 설치되는 원래 방법은라는 이진 스냅 샷을 사용하는 것 app-emulation/emul-linux-*입니다. 이 에뮬레이션 바이너리 패키지에는 젠투 개발자가 컴파일 한 32 비트 라이브러리가 포함되어 있습니다. 각 라이브러리는 함께 조정해야하는 라이브러리 번들을 설치하므로 32 비트 전용 ebuild의 종속성 추적이 더 어렵습니다. 예를 들어, media-libs/alsa-lib32 비트 시스템에서 32 media-libs/alsa-lib비트가 필요한 경우을 설치 하지만 64 비트 multilib 시스템에서는 app-emulation/emul-linux-soundlibs32 비트 버전의 다른 라이브러리 중에서 설치 를 발견해야 합니다 media-libs/alsa-lib. 또한 하나의 바이너리 패키지를 빌드하는 Gentoo 개발자는 각각 의 multilib 및 빌드 시스템 문제를 파악하는 작업을 수행해야합니다.스냅 샷 패키지에 포함 된 라이브러리를 사용하여 유지 관리를 더욱 어렵게합니다. 그리고 가장 중요한 것은 젠투에서 multilib를 사용하는 유일한 옵션 공식 옵션으로 바이너리 패키지를 제공하는 것은 젠투의 정신에 위배됩니다. 모든 것을 스스로 컴파일 할 권리가 있습니다 !
multilib-build.eclass개인이 빌드를 지원함으로써이 동작에서 멀리 이동 설치가 모두 32 비트 및 64 비트 버전을. 예를 들어, wine패키지를 가져 오는 대신 필요한 패키지에 대해 직접 종속성을 지정하기 만하면 app-emulation/emul-linux-*됩니다. ssuominen이 언급 한 포럼 스레드 에서 언급했듯이 :
= app-emulation / emul-linux-x86-xlibs-20130224-r1 파일이 x11-libs /에서 직접 가져 오기 때문에 파일이없는 빈 패키지입니다.
(주 -r1이후로 이름이 바뀌 었습니다은 -r2) 결국, app-emulation/emul-linux-x86-xlibs그 자체가 적절에서 올바른 패키지를 직접 따라 32 비트 전용 패키지로 삭제 될 수 있어야 x11-libs으로, 그 multilib-build.eclass필요한 32 비트 libs와 제공의 도움이됩니다. 여기가 시작 ABI_X86됩니다. 모든 multilib-build.eclass사용이 가능한 패키지는 적어도 새로운 USE-플래그 얻게 abi_x86_32하고 abi_x86_64아마와 abi_x86_x32. EAPI=2스타일 USE 종속성을 사용하면 패키지는 다른 패키지의 32 비트 버전에 의존 할 수 있습니다. x11-libs/libX11로 표시된 경우 ABI_X86="32 64"USE 플래그 abi_x86_32및 abi_x86_64USE 플래그가 설정된 상태로 설치됩니다. 특정 그래픽 패키지에 32 비트 버전의이 필요한 경우 libX11다음을 지정할 수 있습니다.x11-libs/libX11[abi_x86_32]의존성. 이런 식으로이 그래픽 패키지를 표시하려고 시도하고 libX1132 비트 라이브러리를 설치하지 않은 경우 포티지는 거부됩니다. multilib-build.eclass또한 범용이며 32 비트 시스템과 호환됩니다 . useflag를 설정 libX11하지 않으면 설치할 수 없으므로 32 비트 시스템에 동일한 그래픽 패키지를 설치하면 항상 작동 abi_x86_32합니다. 이렇게 app-emulation/emul-linux-x86-xlibs하면 multilib 시스템 에 있을 때와 x11-libs/libX1132 비트 전용 시스템에 직접 의존해야하는 문제가 해결 됩니다. 우리는 multilib 시스템에서보다 깨끗하고 합리적인 패키지 간 종속성을 가지기 위해 노력하고 있습니다. 예를 들어, 직접 의존하는 방법을 모르는 =app-emulation/emul-linux-x86-xlibs-20130224-r2의존했던 이전 패키지 를 계속 작동 시키는 중개자로 존재 합니다.app-emulation/emul-linux-x86-xlibsx11-libs/libX11[abi_x86_32]=app-emulation/emul-linux-x86-xlibs-20130224-r2설치 한 /usr/lib32것처럼 동일한 32 비트 라이브러리가 존재하는지 확인 =app-emulation/emul-linux-x86-xlibs-20130224하지만 바이너리 패키지를 제공하지 않고 종속성을 통해 이러한 32 비트 라이브러리를 빌드하여 젠투 방식으로 설치합니다. virtual이 방법 은 범주 에서 패키지와 매우 유사하게 작동 합니다. 기존 ebuild에 대한 "앞으로"종속성을 설치하지 않습니다.
우리는 multilib-build.eclassmultilib 시스템에 대한 명확한 의존성을위한 길을 열어 놓았습니다. ABI_X86옵션이 있는 패키지 ( abi_x86_*useflags를 사용 하는 것과 동일 )는 USE=abi_x86_32/를 지정한 경우 자체의 32 비트 버전을 설치했습니다 ABI_X86=32. 이 개념은 어떻게 작동합니까 (높은 개념 수준에서)? ebuild 자체를 읽을 수 있습니다. 기본적으로 아이디어는 파이썬 또는 루비이 빌드와 동일하며 여러 버전의 파이썬과 루비를 동시에 설치할 수 있습니다. ebuild는을 상속하면 multilib-build.eclassABI_X86을 반복하며 ABI_X86의 각 항목에 대해 포장 풀기, 컴파일 및 설치 프로세스의 각 단계를 수행합니다. 운반는이 빌드 같은 단계를 모두 통과 이후 src_unpack(), src_compile()및 src_install()순서 (및 기타)과 단 한번의multilib-build.eclass(현재는 multibuild.eclass)를 사용하여 ABI_X86의 각기 다른 값에 대한 디렉토리를 만듭니다. 소스 사본을 각 디렉토리에 압축 해제합니다. 거기에서 각 디렉토리는 특정 ABI를 대상으로 할 때 분기되기 시작합니다. 의 디렉토리 ABI_X86=32것이다 ./configure --libdir=/usr/lib32FLAGS 32 비트를 대상으로 실행 (예 CFLAGS=-m32: 운반 프로파일은 대부분 ABI_X86 = 32을 참조로 ABI = x86 및 ABI_X86 ABI = AMD64로 = 64) (참고 multilib 프로파일의 CFLAGS_x86의 ENVVAR에서 온다). 시src_install()단계에서, 서로 다른 컴파일 된 ABI가 서로 위에 설치되므로 파일에 32 비트 및 64 비트 버전이 모두 있으면 기본 ABI가 승리합니다 (예 : 라이브러리와 PATH에 실행 파일을 모두 설치하는 ebuild는 64 개만 설치 함) -PATH로 실행 가능하지만 32 비트 및 64 비트 라이브러리를 모두 포함합니다. 요약하면 : 설정 한 경우 ABI_X86="32 64"에 make.conf, 어떤 지원하는 모든 패키지 multilib-build.eclass가 각 ABI에 대해 한 번 구축하고 결과를 32 비트 라이브러리에서됨에 따라 컴파일 (나는 시간을 말하는 게 아니에요 ;-)) 약 일의 두 배를 취할 것 /usr/lib32.
ABI_X86아직 공식적인 문서가 있는지 또는 자세한 상태 가 있는지 모르겠습니다 . 현재 사용하는 multilib-build.eclass이 빌드 가 대부분 불안정한 것 같습니다. new-style multilib ABI_X86의 차이점을 이해 한 경우 , 연결된 블로그의 지시 사항에 따라 경험 및 테스트를 시작할 수 있습니다 . 그러나 이전 스타일 바이너리 패키지에 문제가 없다면 기능을 유지해야 한다고 생각합니다 . 당신은 이동해야 당신이 어떤 패키지를 사용하는 경우 직접 다른 패키지의에 따라 useflag (예를 들어, 그리고 그들은 아마도 모두 같은 라이브러리를 설치하기 때문에 공존 할 수없는 즉, ). 빠른app-emulation/emul-linux-x86-xlibs-20130224app-emulation/emul-linux-x86-xlibs-20130224-r2app-emulation/emul-linux-x86-xlibs-20130224-r2abi_x86_32app-emulation/emul-linux-x86-xlibs-20130224x1-libs/libX11[abi_x86_32]/usr/lib32/usr/lib32/libX11.so.6봐 wine-1.7.0.ebuild가 필요하지 않습니다 나에게 제안한다 -r2.
app-emulation/emul-linux-x86하고 다른 일부는 그들의 직접적인 대응 에 의존한다는 것을 의미 합니다. 많은 키워드와 USE 플래그 변경이 필요했지만 모든 것을 컴파일하고 즐겁게 실행할 수 있습니다! :-D