Saya harus mengungkapkan bahwa saya memiliki sedikit pengalaman menggunakan multilib-build.eclassmultilib-style di Gentoo.
ABI_X86adalah USE_EXPANDvariabel; pengaturan ABI_X86="32 64"atau USE="abi_x86_32 abi_x86_64"setara. Pengaturan default ABI_X86, saat tulisan ini dibuat (2013-09-09), untuk default/linux/amd64/13.0profilnya sepertinya adil ABI_X86=64.
Variabel ini mengontrol dukungan multilib eksplisit di ebuild yang menggunakan cara multilib-build.eclassyang lebih mirip Gentoo untuk melakukan multilib daripada metode asli.
Metode asli yang akan diinstal oleh perpustakaan 32-bit di Gentoo adalah melalui snapshot biner bernama app-emulation/emul-linux-*. Masing-masing paket biner emulasi ini berisi seluruh set pustaka 32-bit yang dikompilasi oleh beberapa pengembang Gentoo untuk Anda. Karena masing-masing menginstal seikat perpustakaan yang harus dikoordinasikan bersama, melacak dependensi dari ebuild 32-bit saja lebih sulit. Misalnya, jika Anda memerlukan 32-bit media-libs/alsa-libpada sistem 32-bit, Anda hanya menginstal media-libs/alsa-lib, tetapi pada sistem multilib 64-bit, Anda harus menemukan bahwa app-emulation/emul-linux-soundlibsmenginstal, di antara perpustakaan lain, versi 32-bit media-libs/alsa-lib. Juga, pengembang Gentoo yang membuat satu paket biner seperti itu harus melakukan pekerjaan mencari tahu multilib dan membangun sistem quirks masing - masingdari perpustakaan yang disertakan dalam paket snapshot, membuat pemeliharaan lebih sulit. Dan, yang paling penting, menyediakan paket biner sebagai satu-satunya opsi opsi resmi untuk menggunakan multilib di Gentoo bertentangan dengan semangat Gentoo. Anda harus memiliki hak untuk mengkompilasi semuanya sendiri!
The multilib-build.eclassbergerak jauh dari perilaku ini dengan membantu ebuild individu menginstal baik versi 32-bit dan 64-bit. Ini harus memungkinkan, misalnya, wineuntuk hanya perlu menentukan dependensi secara langsung terhadap paket yang dibutuhkan alih-alih harus menarik app-emulation/emul-linux-*paket. Seperti ssuominen menyebutkan di utas forum yang Anda referensikan :
= app-emulation / emul-linux-x86-xlibs-20130224-r1 yang merupakan paket kosong yang tidak memiliki file karena file datang sekarang langsung dari x11-libs /
(Catatan yang -r1sejak saat itu telah diubah namanya menjadi -r2) Akhirnya, paket app-emulation/emul-linux-x86-xlibsitu sendiri harus dapat dihapus karena paket 32-bit saja secara tepat bergantung langsung pada paket yang benar x11-libs, dengan multilib-build.eclassbantuan, menyediakan lib 32-bit yang diperlukan. Di sinilah ABI_X86berperan. Setiap multilib-build.eclasspaket yang diaktifkan akan mendapatkan setidaknya flag USE baru abi_x86_32dan abi_x86_64dan mungkin abi_x86_x32. Menggunakan EAPI=2dependensi USE-style , paket dapat bergantung pada versi 32-bit dari paket lain. Jika x11-libs/libX11muncul sementara ABI_X86="32 64", maka itu harus diinstal dengan flag USE abi_x86_32dan flag abi_x86_64USE yang ditetapkan. Jika paket grafis tertentu membutuhkan versi 32-bit libX11, itu dapat menentukanx11-libs/libX11[abi_x86_32]dalam ketergantungannya. Dengan cara ini, jika Anda mencoba untuk menginstal paket grafis ini dan libX11belum menginstal lib 32-bit, portage akan menolak. multilib-build.eclassjuga universal dan kompatibel dengan sistem 32-bit: menginstal paket grafis yang sama ini pada sistem 32-bit akan selalu berfungsi karena tidak mungkin untuk menginstal libX11tanpa menggunakan abi_x86_32tag bendera yang ditetapkan. Ini memecahkan masalah yang perlu bergantung pada app-emulation/emul-linux-x86-xlibskapan pada sistem multilib dan langsung x11-libs/libX11pada sistem 32-bit saja. Kami membuka jalan menuju ketergantungan antar paket yang lebih bersih dan masuk akal pada sistem multilib. =app-emulation/emul-linux-x86-xlibs-20130224-r2hadir sebagai perantara yang memungkinkan semua paket lama yang dulu bergantung pada app-emulation/emul-linux-x86-xlibsyang tidak tahu bagaimana cara bergantung secara langsung, misalnya x11-libs/libX11[abi_x86_32], untuk tetap berfungsi.=app-emulation/emul-linux-x86-xlibs-20130224-r2memastikan bahwa pustaka 32-bit yang sama ada di /usr/lib32seolah-olah =app-emulation/emul-linux-x86-xlibs-20130224telah diinstal, tetapi apakah itu cara Gentoo dengan membangun pustaka 32-bit ini melalui dependensi daripada menyediakan paket biner. Ini berperilaku seperti paket dalam virtualkategori dengan cara ini: ia tidak menginstal apa pun, hanya "meneruskan" dependensi untuk ebuild yang ada.
Kita telah melihat bagaimana multilib-build.eclassmembuka jalan bagi ketergantungan yang lebih bersih pada sistem multilib. Paket apa pun yang memiliki ABI_X86opsi (sama dengan mengatakan ia abi_x86_*menggunakanflags) telah menginstal versi 32-bit sendiri jika Anda telah menentukan USE=abi_x86_32/ ABI_X86=32. Bagaimana cara kerjanya (pada tingkat konseptual yang tinggi)? Anda dapat membaca ebuild itu sendiri. Pada dasarnya idenya sama dengan ebuild python atau ruby yang memiliki opsi untuk menginstal sendiri beberapa versi python dan ruby secara bersamaan. Ketika sebuah ebuild mewarisi multilib-build.eclass, itu melingkupi ABI_X86 dan melakukan setiap langkah proses pembongkaran, kompilasi, dan instalasi untuk setiap entri di ABI_X86. Sejak portage melewati semua tahapan ebuild seperti src_unpack(), src_compile(), dan src_install()(dan lain-lain) dalam rangka dan hanya sekali, yangmultilib-build.eclass(saat ini, dengan bantuan dari multibuild.eclass) uses menciptakan direktori untuk setiap nilai ABI_X86 yang berbeda. Ini akan membongkar salinan sumber ke masing-masing direktori ini. Dari sana, masing-masing direktori ini mulai menyimpang karena masing-masing menargetkan ABI tertentu. Direktori untuk ABI_X86=32akan ./configure --libdir=/usr/lib32dijalankan dengan FLAGS yang menargetkan 32-bit (mis., CFLAGS=-m32Berasal dari CFLAGS_x86 envvar profil multilib (catatan: profil portage sebagian besar merujuk ke ABI_X86 = 32 karena ABI = x86 dan ABI_X86 = 64 sebagai ABI = amd64)). Selamasrc_install()fase, semua ABI yang dikompilasi yang berbeda dipasang lebih dari satu sama lain sehingga ketika setiap file memiliki versi 32-bit dan 64-bit, ABI asli menang (misalnya, ebuild yang menginstal kedua perpustakaan dan yang dapat dieksekusi di PATH akan menginstal hanya 64 -bit dieksekusi ke PATH tetapi termasuk perpustakaan 32-bit dan 64-bit). Singkatnya: ketika Anda mengatur ABI_X86="32 64"di make.conf, paket yang mendukung multilib-build.eclassakan mengambil kira-kira dua kali jumlah pekerjaan (Saya tidak mengatakan waktu ;-)) untuk mengkompilasi karena sedang dibangun sekali untuk setiap ABI dan hasil dalam 32-bit perpustakaan di /usr/lib32.
Saya tidak tahu apakah belum ada dokumentasi resmi ABI_X86atau status detailnya. Ebuild menggunakan multilib-build.eclasstampaknya sebagian besar tidak stabil untuk saat ini. Anda dapat mengikuti instruksi di blog yang Anda tautkan untuk mulai mengalami dan menguji ABI_X86jika Anda memahami perbedaan antara app-emulation/emul-linux-x86-xlibs-20130224dan multilib gaya baru app-emulation/emul-linux-x86-xlibs-20130224-r2. Tapi, jika Anda setuju dengan paket biner gaya lama, saya pikir itu app-emulation/emul-linux-x86-xlibs-20130224harus tetap fungsional. Anda hanya perlu pindah ke -r2jika Anda menggunakan paket apa pun yang secara langsung bergantung pada abi_x86_32tag penggunaan paket lain (misalnya, app-emulation/emul-linux-x86-xlibs-20130224dan x1-libs/libX11[abi_x86_32]tidak dapat hidup berdampingan karena keduanya mungkin menginstal pustaka yang sama /usr/lib32, yaitu /usr/lib32/libX11.so.6). Sebuah cepatlihat wine-1.7.0.ebuildmenyarankan kepada saya bahwa itu tidak perlu -r2.
app-emulation/emul-linux-x86dan sebagian lainnya bergantung pada mitra langsung mereka. Butuh banyak keywording dan perubahan flag USE, tapi saya punya segalanya untuk dikompilasi dan berjalan bersama dengan bahagia! :-D