젠투에서 ABI_X86 사용하기

나는 Gentoo에서 -style multilib를 사용한 경험이 거의 없다는 점을 밝혀야 합니다 multilib-build.eclass.

ABI_X86는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.

이 변수는 multilib-build.eclass원래 접근 방식보다 젠투와 더 유사한 multilib 접근 방식을 사용하여 ebuild에서 명시적인 multilib 지원을 제어합니다.

젠투에 32비트 라이브러리를 설치하는 원래 방법은 app-emulation/emul-linux-*. 이러한 시뮬레이션된 바이너리 패키지 각각에는 일부 젠투 개발자가 여러분을 위해 컴파일한 완전한 32비트 라이브러리 세트가 포함되어 있습니다. 32비트 전용 ebuild에 대한 종속성을 추적하는 것은 각 ebuild가 함께 조정되어야 하는 라이브러리 세트를 설치하기 때문에 더 어렵습니다. 예를 들어, media-libs/alsa-lib32비트 시스템에 32비트 버전이 필요한 경우 media-libs/alsa-lib간단히 설치하면 됩니다. 또한 이러한 바이너리 패키지를 빌드하는 젠투 개발자는 다음 문제를 해결해야 합니다: multilib 및 빌드 시스템의 단점 파악app-emulation/emul-linux-soundlibsmedia-libs/alsa-lib각스냅샷 패키지에 포함된 라이브러리 수로 인해 유지 관리가 더 어려워집니다. 그리고 가장 중요한 것은 Gentoo에서 multilib를 사용하기 위한 유일한 공식 옵션으로 바이너리 패키지를 제공하는 것은 Gentoo의 정신에 어긋나는 것입니다. 컴파일할 수 있는 권한이 있어야 합니다.모든 것당신 자신!

multilib-build.eclass단일 ebuild 설치를 도와서 이 동작을 제거하십시오.둘 다32비트 및 64비트 버전. 예를 들어, 패키지를 wine가져올 필요 없이 필요한 패키지에 대해서만 종속성을 직접 지정할 수 있어야 합니다. app-emulation/emul-linux-*ssuominen에서 언급했듯이귀하가 참조한 포럼 주제:

=app-emulation/emul-linux-x86-xlibs-20130224-r1 파일이 이제 x11-libs/에서 직접 제공되므로 파일이 없는 빈 패키지입니다.

( -r1이후 이름이 변경되었습니다 .) 필요한 32비트 라이브러리를 제공하는 의 도움을 받아 32 비트 패키지만 올바른 패키지에 직접적으로 의존하므로 -r2결국 app-emulation/emul-linux-x86-xlibs자체적으로 제거할 수 있어야 합니다 . 이것이 작용하는 곳 입니다 . 활성화된 모든 패키지는 최소한 새로운 USE 플래그 와 .x11-libsmultilib-build.eclassABI_X86multilib-build.eclassabi_x86_32abi_x86_64abi_x86_x32EAPI=2-스타일 USE 의존성, 패키지는 다른 패키지의 32비트 버전에 종속될 수 있습니다. x11-libs/libX11있는 경우 USE-flags 및 USE-flags 설정을 ABI_X86="32 64"사용하여 설치해야 합니다 . 특정 그래픽 패키지에 32비트 버전이 필요한 경우 종속성에서 이를 지정할 수 있습니다. 이렇게 하면 이 그래픽 패키지를 이머지하려고 하는데 32비트 라이브러리가 설치되어 있지 않으면 포티지가 거부합니다. 또한 범용적이고 32비트 시스템과 호환됩니다. 32비트 시스템에 동일한 그래픽 패키지를 설치하면 use 플래그를 설정하지 않고는 설치할 수 없기 때문에 항상 작동합니다. 이는 다중 저장소 시스템에 대한 종속성을 요구하지만 32비트 전용 시스템에 대한 직접적인 종속성을 요구하는 문제를 해결합니다. 우리는 다중 리포지토리 시스템에서 더 명확하고 논리적인 패키지 간 종속성을 가질 수 있는 길을 닦고 있습니다.abi_x86_32abi_x86_64libX11x11-libs/libX11[abi_x86_32]libX11multilib-build.eclasslibX11abi_x86_32app-emulation/emul-linux-x86-xlibsx11-libs/libX11=app-emulation/emul-linux-x86-xlibs-20130224-r2중개자로 존재하므로 한때 의존했지만 직접 의존하는 방법을 모르는 app-emulation/emul-linux-x86-xlibs이전 패키지(예: )가 여전히 작동하도록 허용합니다. 동일한 32비트 라이브러리가 설치된 것처럼 존재하는지 확인하세요 . 단, 바이너리 패키지를 제공하는 대신 젠투 방식으로 종속성을 통해 라이브러리를 빌드합니다.x11-libs/libX11[abi_x86_32]=app-emulation/emul-linux-x86-xlibs-20130224-r2/usr/lib32=app-emulation/emul-linux-x86-xlibs-20130224이는 이 범주의 패키지와 매우 유사하게 작동합니다 virtual. 아무것도 설치하지 않고 기존 ebuild의 종속성을 "전달"할 뿐입니다.

multilib-build.eclass우리는 다중 라이브러리 시스템에 대한 보다 명확한 종속성을 위한 길을 닦는 방법을 살펴보았습니다 . /를 지정하면 ABI_X86옵션( abi_x86_*useflags가 있다는 것과 동일)이 있는 모든 패키지에는 자체 32비트 버전이 설치됩니다. 이것은 어떻게 작동합니까(높은 개념 수준에서)? ebuild 자체를 읽을 수 있습니다. 기본적으로 아이디어는 여러 버전의 Python과 Ruby를 동시에 설치할 수 있는 옵션이 있는 Python 또는 Ruby ebuild와 동일합니다. ebuild가 상속되면 ABI_X86을 반복하고 ABI_X86의 각 항목에 대한 압축 풀기, 컴파일 및 설치 프로세스의 각 단계를 수행합니다. 포티지는 , , (다른 것 중에서)와 같은 모든 ebuild 단계를 순서대로 거치고 단 한 번만 수행하므로, 를 사용하여 ABI_X86의 각각 다른 값에 대해 디렉토리가 생성됩니다(현재 의 도움으로). 각 디렉터리에 소스 코드 복사본이 추출됩니다. 여기에서 각 디렉터리는 특정 ABI를 대상으로 하므로 각 디렉터리가 갈라지기 시작합니다. 이 디렉토리는 32비트용 FLAGS를 사용하여 실행됩니다(예: multilib 프로필의 CFLAGS_x86 환경 변수(참고: 포티지 프로필은 주로 ABI_X86=32를 ABI=x86으로, ABI_X86=64를 ABI=amd64로 참조). 이 단계에서는 모든 다른 빌드 ABI가 서로 설치되므로 파일에 32비트와 64비트 버전이 모두 있을 때 기본 ABI가 승리합니다(예: PATH에 라이브러리와 실행 파일을 모두 설치하는 ebuild는 64비트만 설치합니다) 실행 파일은 PATH로 이동하지만 32비트 및 64비트 라이브러리를 모두 포함합니다.USE=abi_x86_32ABI_X86=32multilib-build.eclasssrc_unpack()src_compile()src_install()multilib-build.eclassmultibuild.eclassABI_X86=32./configure --libdir=/usr/lib32CFLAGS=-m32src_install()ABI_X86="32 64"요약하자면 , 이를 설정할 때 make.conf지원되는 모든 패키지는 multilib-build.eclass각 ABI에 대해 한 번 빌드되고 32비트 라이브러리를 생성하기 때문에 컴파일하는 데 약 두 배의 작업(시간을 의미하지는 않습니다 ;-)이 소요됩니다 /usr/lib32.

ABI_X86공식 문서 나 자세한 상태 가 있는지는 모르겠습니다 . 현재 사용중인 Ebuild는 multilib-build.eclass대부분 불안정한 것 같습니다. multilib과 new multilib의 차이점을 이해하셨다면 ABI_X86링크된 블로그의 안내에 따라 체험과 테스트를 시작해 보실 수 있습니다.app-emulation/emul-linux-x86-xlibs-20130224app-emulation/emul-linux-x86-xlibs-20130224-r2그러나 레거시 바이너리 패키지에 만족한다면 app-emulation/emul-linux-x86-xlibs-20130224계속 작동해야 한다고 생각합니다.-r2패키지를 사용하고 있다면 다음으로 이동하면 됩니다.abi_x86_32다른 패키지의 useflag 에 직접적으로 의존(예를 들어 app-emulation/emul-linux-x86-xlibs-20130224및 는 x1-libs/libX11[abi_x86_32]둘 다 동일한 라이브러리를 에 설치할 수 있으므로 공존할 수 없습니다 /usr/lib32. /usr/lib32/libX11.so.6) ㅏ빠른한 번 보면 wine-1.7.0.ebuild그럴 필요가 없다는 것을 알 수 있습니다 -r2.

abi_x86_x32(abi_x86_32와 다름) 사용 플래그도 있습니다. 이는 실험적이며 반 64비트 애플리케이션을 구축하기 위한 것입니다. 유일한 차이점은 4바이트 포인터가 있다는 것입니다. 이는 메모리 사용량을 4GiB로 제한하고 대부분의 경우 모든 64비트 명령어 사용을 허용하면서 오버헤드를 줄입니다.

현재 상황은 지옥입니다. 문제는 많은 패키지가 "반차폐"되어 있는 것 같습니다... 정확한 용어는 모르겠지만 일부 패키지에는 "abi_x86_32" 사용 플래그와 함께 "~amd64" 키워드가 있는 것 같습니다. 반면 " amd64 "는 플래그를 사용하지 않습니다. 결과적으로 업데이트하는 동안 "abi_x86_32"를 활성화했지만 각 클래스에 대해 이를 구성하지 않는 한 이머지는 여전히 ABI_X86="(64)(-32)" 패키지를 설치합니다. 패키지 추가 "~amd64 ". 직접 이머징하지 않고 종속성으로 끌어온 경우 해당 변경 사항을 자동으로 보호 해제할 수 없습니다. 이머지는 단지 필수 "abi_x86_32" 사용 플래그가 있는 해당 패키지의 종속성을 충족할 수 없다는 것을 알려줄 뿐입니다. 그래서 각 패키지를 package.keywords에 "~amd64"로 하나씩 추가해야 합니다. 이것은 많은 수작업입니다. 어떤 패키지 버전에 대해 이 작업을 수행해야 합니까? 내가 정말로 원하는 것이 무엇인지는 말할 수 없습니다. 그것은 ""amd64" 태그가 붙었지만 플래그가 사용되지 않은 버전용"입니다. 지금 보고 있는 특정 최신 버전을 넣으면 향후 업데이트가 복잡해질 수도 있고, 모든 버전을 넣은 다음 잠재적으로 64비트에서도 안정적이라고 표시되지 않은 버전을 설치할 수도 있습니다.

간접적으로 관련된 정보: 현재 systemd의 전체 KDE 데스크탑 시스템은 (에뮬레이션 패키지 없이) 순수 multilib 모드로 컴파일될 수 있습니다. 현재 유일한 문제는 독점 nvidia-drivers 패키지에 있지만 현재 오픈 소스 패키지를 사용하여 해결할 수 있습니다.

시작하는 방법(추가 링크 포함): https://forums.gentoo.org/viewtopic-t-985380-highlight-.html

젠투 Multilib 포팅 상태https://wiki.gentoo.org/wiki/Multilib_porting_status