젠투에서 ABI_X86 사용 있듯이, 이것은

Gentoo 시스템을 업데이트 한 지 몇 달이 지났습니다. 그리고 당신이 상상할 수 있듯이, 이것은 내가 가야 할 많은 패키지 (및 USE 변경 사항)가 있음을 의미합니다. 내 시스템은 “amd64″(multilib)이지만 “~ amd64″의 수동 키워드 패키지가 많이 있습니다.

어쨌든이 업데이트에서는 “ABI_X86″USE 플래그가 계속 표시됩니다. 이게 뭐야? 이것은 새로운 것입니다. “eselect news list”에는 아무것도 없습니다.

:이 주제 발견 http://forums.gentoo.org/viewtopic-t-953900-start-0.html을 . 그것은 그것을 사용하는 방법을 보여주는 것처럼 보였지만 이것에 대한 “실제”문서가 있습니까? 무엇을합니까? 내가 뭘하고 가정 에 세트 “ABI_X86″에? multilib 시스템이 있습니다. “64”를 원하지만 “32”와 “x32″는 무엇입니까? 내가 여기서해야 할 일이 혼란 스럽습니다.

Emerge는 슬롯 충돌에 대해 많은 소리를 지르며 “ABI_X86″과 관련이있는 것 같습니다 (오류를 정확하게 잊어 버렸지 만 하나는 zlib라는 것을 기억합니다).

그래서, 그것이 무엇 ABI_X86이며 어떻게 사용되는지에 대한 “공식적인”문서가 있습니까?

내가 링크 된 스레드에서, 나는이 페이지를 발견 : http://kicherer.org/joomla/index.php/en/blog/liste/29-transition-of-emul-packages-to-true-multilib를 하지만, 내가 원하는 키워드로 이동하여 내 항목을 수정하기 전에 내가 무엇을하는지 알고 싶습니다 make.conf.

추신 : 나는 “package.keywords”파일에 대부분의 “app-emulation / emul-linux-x86″패키지 (당시 필자가 필요했던 것)를 가지고있다.



답변

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_32abi_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.6wine-1.7.0.ebuild가 필요하지 않습니다 나에게 제안한다 -r2.


답변

abi_x86_x32 (abi_x86_32와 동일하지 않음) 사용 플래그도 있습니다. 이것은 실험적이며 세미 64 비트 응용 프로그램을 빌드하기위한 것입니다. 유일한 차이점은 4 바이트 포인터가 있다는 것입니다. 이는 메모리 사용량을 4GiB로 제한하고 대부분의 경우 오버 헤드를 줄이면서 64 비트 명령어를 모두 사용할 수 있도록합니다.


답변

현재 상황은 정말 지옥입니다. 문제는 많은 패키지가 “반 마스크”의 일종 인 것 같습니다 … 정확한 용어를 모르지만 일부 패키지는 “abi_x86_32″사용 플래그 및 “amd64″없이 키워드 “~ amd64″인 것으로 보입니다. 그 플래그를 사용하는 … 결과는 내 업데이트 중에 “abi_x86_32″를 사용하도록 설정하지만 각 패키지마다 “~ amd64″를 추가하지 않으면 ABI_X86 = “(64) (-32)”로 패키지를 설치합니다. 그리고 직접 발생하는 대신 종속성으로 가져 오면 해당 변경 사항을 자동 마스크 해제 할 수 없습니다. emerge는 필요한 “abi_x86_32″사용 플래그를 사용하여 해당 패키지에 대한 종속성을 만족시킬 수 없음을 나타냅니다. 따라서 “~ amd64″를 사용하여 각 패키지를 하나씩 package.keywords에 추가해야합니다. 많은 수동 작업입니다 … 그리고 어떤 패키지 버전을 사용해야합니까? “실제 사용 플래그없이”amd64 “로 표시된 버전의 경우 실제로 원하는 것을 말할 수 없습니다. 현재 볼 수있는 특정 최신 버전을 배치하여 향후 업데이트를 복잡하게 만들거나 모든 버전을 배치 한 다음 64 비트에서도 안정적으로 표시되지 않은 버전을 설치할 수 있습니다 …


답변

간접적으로 관련된 정보 : 현재 systemd의 완전한 KDE 데스크탑 시스템은 순수한 다중 라이브러리 방식으로 에뮬레이션 패키지없이 컴파일 될 수 있습니다. 유일한 문제는 이제 독점적 인 nvidia-drivers 패키지이지만, 지금은 오픈 소스 패키지를 사용하여 해결할 수 있습니다.

시작 방법 (다른 링크가 포함되어 있음) :
https://forums.gentoo.org/viewtopic-t-985380-highlight-.html

젠투 멀티 라이브 포팅 상태 https://wiki.gentoo.org/wiki/Multilib_porting_status


답변