Gentoo’da ABI_X86’yı kullanma

Gentoo sistemimi güncellememden bu yana aylar geçti. Ve tahmin edebileceğiniz gibi, bu benim gözden geçirmem gereken çok sayıda paket (ve USE değişikliği) olduğu anlamına geliyor. Sistemim "amd64" (multilib) 'dir, ancak "~ amd64" adresinden el ile anahtar kelimeli birçok paketim var.

Neyse, bu güncellemede "ABI_X86" USE bayraklarını görmeye devam ediyorum. Bu nedir? Bu yeni. "Haber listesinde" seçiminde hiçbir şey yok.

Bu konuyu buldum: http://forums.gentoo.org/viewtopic-t-953900-start-0.html . Bu nasıl kullanılacağını gösteriyor gibiydi, ancak bunun için "gerçek" dokümanlar var mı? Bu ne işe yarıyor? Ne am gerekiyordu için sette "ABI_X86" için? Multilib sistemim var. "64" istediğimi sanıyorum, ama sonra "32" ve "x32" nedir? Burada yapmam gerekeni kafam karıştı.

Emerge, slot çatışmaları hakkında çok bağırıyor ve "ABI_X86" ile alakalı görünüyorlar (Hataları tamamen unutuyorum ama birinin zlib olduğunu hatırlıyorum).

Peki, ne ABI_X86olduğu ve nasıl kullanılacağı hakkında herhangi bir "resmi" belge var mı?

Bağladığım iş parçacığından bu sayfayı buldum: http://kicherer.org/joomla/index.php/en/blog/liste/29-transition-of-emul-packages-to-true-multilib , ama istiyorum Anahtar kelimeye gitmeden önce ne yaptığımı bilmek istiyorum make.conf.

PS "package.keywords" dosyamdaki "app-emulation / emul-linux-x86" paketlerinin çoğunda (o sırada ihtiyaç duyduğum paketler) var.

multilib-build.eclassGentoo'da -style multilib'i kullanma konusunda çok az deneyimim olduğunu açıklamalıyım .

ABI_X86bir USE_EXPANDdeğişkendir; ayarı ABI_X86="32 64"veya USE="abi_x86_32 abi_x86_64"eşdeğerdir. ABI_X86’nın varsayılan ayarı, bu yazı itibariyle (2013-09-09), default/linux/amd64/13.0profil için aynı görünüyor ABI_X86=64.

Bu değişken multilib-build.eclass, orijinal yöntemden çok multilib yapmanın daha Gentoo benzeri bir yolu olan ebuild'lerde açık multilib desteğini kontrol eder .

Gentoo'da 32 bit kitaplıkların kurulacağı orijinal yöntem, adlandırılmış ikili anlık görüntüler aracılığıyladır app-emulation/emul-linux-*. Bu emülasyon ikili paketlerinin her biri, sizin için bir Gentoo dev tarafından derlenen bir dizi 32-bit kitaplık içerir. Her biri birlikte koordine edilmesi gereken bir kütüphaneler paketi kurduğundan, yalnızca 32 bit ebuild'lerin bağımlılıklarını izlemek daha zordur. Örneğin, media-libs/alsa-lib32 bit bir sistemde 32 bit gerekiyorsa , sadece yükleyin media-libs/alsa-lib, ancak 64 bit multilib bir sistemde, app-emulation/emul-linux-soundlibsdiğer kütüphanelerin yanı sıra 32 bitlik sürümün de yüklendiğini keşfetmeniz gerekir media-libs/alsa-lib. Ayrıca, Gentoo dev bu tür bir ikili paketi inşa etmek için her birinin multilib ve yapı sistemi tuhaflıklarını bulma işini yapmalıdır.Anlık görüntü paketindeki kitaplıklardan biri, bakımı zorlaştırır. Ve en önemlisi, Gentoo'da multilib kullanmak için tek seçenek resmi seçenek olarak ikili paketler sağlamak Gentoo'nun ruhuna aykırı. Her şeyi kendiniz derleme hakkınız olmalı !

multilib-build.eclassBireysel ebuild'leri yardım ederek bu davranıştan uzak hamle yüklemek hem 32 bit ve 64 bit sürümleri. Bu, örneğin, winepaketleri çekmeye ihtiyaç duymak yerine, yalnızca ihtiyaç duyduğu paketlere doğrudan bağımlılıklar belirtmeye ihtiyaç duymasına izin vermelidir app-emulation/emul-linux-*. Ssuominen'in bahsettiğiniz forum başlığında belirtildiği gibi :

= app-emulation / emul-linux-x86-xlibs-20130224-r1 olan ve dosyalar doğrudan boş olan x11-libs /

(O -r1zamandan beri yeniden adlandırıldığına dikkat edin -r2) Sonunda, app-emulation/emul-linux-x86-xlibsyalnızca 32-bit-paketler uygun şekilde doğrudan doğru şekilde doğru paketlere bağlı olarak bırakılabilmelidir, x11-libsbunun da multilib-build.eclassyardımı ile gerekli 32-bit kütüphaneleri sağlar. Burası ABI_X86devreye giriyor. Herhangi multilib-build.eclassetkinleştirilmiş paket en azından yeni KULLANIMI-bayraklarını kazanır abi_x86_32ve abi_x86_64muhtemelen ve abi_x86_x32. EAPI=2Stil USE bağımlılıklarını kullanarak , paketler diğer paketlerin 32 bit sürümlerine bağlı olabilir. Eğer x11-libs/libX11ortaya çıkarsa , ABI_X86="32 64"USE bayrakları abi_x86_32ve abi_x86_64USE bayrakları belirlenir. Belirli bir grafik paketin 32 bit sürümüne ihtiyacı libX11varsa, belirtebilirx11-libs/libX11[abi_x86_32]bağımlılıklarında. Bu şekilde, bu grafik paketini ortaya çıkarmaya çalışırsanız ve libX1132 bit lib'ler yüklememişseniz, portage reddedecektir. multilib-build.eclassAyrıca evrenseldir ve 32-bit sistemlerde uyumludur: o yüklemek mümkün değildir, çünkü bir 32 bit sistemde aynı grafik paketini yükleyerek her zaman çalışır libX11onun olmadan abi_x86_32useflag olmak seti. Bu, app-emulation/emul-linux-x86-xlibsmultilib bir sisteme ve doğrudan x11-libs/libX11sadece 32-bit bir sisteme ne zaman bağlı olacağınız sorununu çözer . Multilib sistemlerde daha temiz ve mantıklı bir paketler arası bağımlılığa sahip olmanın yolunu açıyoruz. =app-emulation/emul-linux-x86-xlibs-20130224-r2Bağımlı olarak kullanılan eski paketlerin app-emulation/emul-linux-x86-xlibs, örneğin doğrudan çalışmaya nasıl dayanacağını bilmeyen bir aracı olarak var x11-libs/libX11[abi_x86_32].=app-emulation/emul-linux-x86-xlibs-20130224-r2aynı 32-bit kütüphanelerin kurulmuşmuş /usr/lib32gibi olduğundan emin olur =app-emulation/emul-linux-x86-xlibs-20130224, ancak bu 32-bit kütüphaneleri bir ikili paket sağlamak yerine bağımlılıkları üzerinden oluşturarak Gentoo yöntemini yapar. Bu virtualkategorideki paketlere çok benzer şekilde davranır : hiçbir şey yüklemez, mevcut ebuild'ler için sadece "ileri" bağımlılıklar kurar.

multilib-build.eclassMultilib sistemlerdeki daha temiz bağımlılıkların nasıl önünü açtığını gördük. ABI_X86Seçenekleri olan herhangi bir paket (bunun abi_x86_*useflags olduğunu söylemekle aynı şey ), USE=abi_x86_32/ belirtmişseniz, kendisinin 32 bit sürümünü yüklemiş ABI_X86=32. Bu nasıl çalışır (üst düzeyde kavramsal düzeyde)? Ebuild'in kendisini okuyabilirsiniz. Temel olarak, fikir aynı anda birçok python ve ruby ​​sürümü için kendilerini yükleme seçeneğine sahip python veya ruby ​​ebuildds ile aynıdır. Bir multilib-build.eclassebuild devraldığında , ABI_X86 üzerinde dolaşır ve ABI_X86'daki her giriş için açma, derleme ve yükleme işleminin her adımını gerçekleştirir. Portage Ebuild gibi fazların her geçtiğinden src_unpack(), src_compile()ve src_install()sırayla (ve diğerleri) ve yalnızca bir kez,multilib-build.eclass(şu anda, kullanımı ile multibuild.eclass) kullanır ABI_X86 her farklı değeri için bir dizin oluşturur. Bu dizinlerin her birine kaynakların bir kopyasını açacaktır. Oradan, bu dizinlerin her biri, her biri belirli bir ABI'yı hedef aldığı için ayrılmaya başlar. Dizin ABI_X86=32olacak ./configure --libdir=/usr/lib32BAYRAKLARI 32-bit hedeflemesi ile çalıştırın (örn CFLAGS=-m32: Portage profilleri çoğunlukla ABI_X86 = 32 başvurmak gibi ABİ = x86 ve ABI_X86 ABI = amd64'tür olarak = 64) (not multilib profilin CFLAGS_x86 envvar gelir). Esnasındasrc_install()Bu aşamada, tüm farklı derlenmiş ABI'lerin hepsi birbirinin üzerine kurulur, böylece herhangi bir dosya hem 32-bit hem de 64-bit sürümlere sahip olduğunda, yerel ABI kazanır (örneğin, hem kütüphaneleri hem de PATH'de çalıştırılabilir bir ebuild, yalnızca 64 -bit PATH içine çalıştırılabilir ancak hem 32 bit hem de 64 bit kütüphaneleri içerir). Özetle: Eğer ayarladığınızda ABI_X86="32 64"içinde make.conf, hangi destekleri herhangi bir paket multilib-build.eclassher ABI için bir kez inşa edilmiş ve sonuçlar, 32-bit kütüphanelerde de ediliyor olarak derlemek (Zamanım demiyorum ;-)) kabaca işin iki katını alacak /usr/lib32.

ABI_X86Henüz resmi bir belge olup olmadığını veya ayrıntılı durumunu bilmiyorum . Ebuild'ler multilib-build.eclassşu an için çoğunlukla kararsız görünüyor. Yeni stil multilib ile ABI_X86arasındaki farkı app-emulation/emul-linux-x86-xlibs-20130224anlarsanız, deneyimlemeye ve test etmeye başlamak için bağlantılı blogdaki talimatları uygulayabilirsiniz app-emulation/emul-linux-x86-xlibs-20130224-r2. Ancak, eski stil ikili paketinde sorun yaşarsanız, bunun app-emulation/emul-linux-x86-xlibs-20130224işlevsel kalması gerektiğini düşünüyorum . Yalnızca geçmek gerekir -r2herhangi bir paket kullanıyorsanız doğrudan başka paketin bağlıdır abi_x86_32useflag (örneğin, app-emulation/emul-linux-x86-xlibs-20130224ve x1-libs/libX11[abi_x86_32]muhtemelen ikisi aynı kütüphane kurmak çünkü arada bulunamaz /usr/lib32yani /usr/lib32/libX11.so.6). bir hızlıbak wine-1.7.0.ebuildbana ihtiyaç duymadığını gösteriyor -r2.

Ayrıca abi_x86_x32 (abi_x86_32 ile aynı değildir) bayrağı kullanılır. Bu, deneysel ve yarı 64bit uygulamalar oluşturmak için tasarlanmıştır. Tek fark, 4 byte işaretçilerine sahip olmaları. Bu, bellek kullanımını 4GiB olarak sınırlandırır ve çoğu durumda ek yükü azaltırken, 64bit komutlarının tümünü kullanmanıza izin verir.

Şu anda durum gerçek cehennem. Sorun pek çok paketin "yarı maskeli" olması gibi görünüyor ... Kesin terminolojiyi bilmiyorum, ancak bazı paketlerin "abi_x86_32" işaretini kullanmadan "~ amd64" ve "amd64" anahtar kelimelerinden bahsedildiği anlaşılıyor. bayrak kullanır ... Sonuç olarak, güncelleme sırasında "abi_x86_32" özelliğini etkinleştiririm, ancak bu paketlerin her birine "~ amd64" eklemediğim sürece emerge hala ABI_X86 = "(64) (-32)" paketlerini yüklüyor. Ve doğrudan ortaya çıkma yerine bir bağımlılık olarak çekilirse, bu değişimin autounmask-write için bir teklifi yoktur - sadece ortaya çıkması, bu paketin bağımlılığını gerekli "abi_x86_32" kullanım bayrağıyla karşılayamayacağını söyler. Bu yüzden her bir paketi birer birer "~ amd64" ile package.keywords dosyasına eklemeliyim. Çok fazla manuel çalışma var. Ve hangi paket sürümü için yapmalıyım? Gerçekten istediğimi söyleyemem, yani "amd64" işaretli sürümler için, bu bayrak kullanılmadan ". Şimdi gördüğüm en son sürümü ya da gelecekteki güncellemelerini karmaşıklaştırabilir ya da tüm sürümleri ekleyebilir ve sonra 64bit için bile kararlı olarak işaretlenmemiş sürümleri yükleyebilirim ...

Dolaylı olarak ilgili bilgi: Bugünden itibaren sistemde tam KDE masaüstü sistemi saf çok dilli bir şekilde derlenebilir (öykünme paketi yok). Tek sorun şu anda tescilli nvidia sürücüleri paketidir, ancak şimdilik açık kaynaklı olanı kullanarak çözülebilir.

Başlangıç ​​noktası (orada bulunan diğer bağlantılar): https://forums.gentoo.org/viewtopic-t-985380-highlight-.html

Gentoo Multilib taşıma durumu https://wiki.gentoo.org/wiki/Multilib_porting_status