Sử dụng ABI_X86 trong Gentoo

Đã vài tháng kể từ khi tôi cập nhật hệ thống Gentoo của mình. Và, như bạn có thể tưởng tượng, điều này có nghĩa là có rất nhiều gói (và USE thay đổi) tôi cần phải đi qua. Hệ thống của tôi là "amd64" (multilib), nhưng tôi có rất nhiều gói từ khóa thủ công từ "~ amd64".

Dù sao, trong bản cập nhật này, tôi vẫn thấy các cờ USE "ABI_X86". Cái gì thế này? Điều này là mới. Không có gì trong "danh sách tin tức eselect" về nó.

Tôi tìm thấy chủ đề này: http://forums.gentoo.org/viewtopic-t-953900-start-0.html . Điều đó dường như cho thấy làm thế nào để sử dụng nó, nhưng, có tài liệu "thực sự" nào cho việc này không? Nó làm gì? Tôi phải làm gì để đặt "ABI_X86" thành? Tôi có một hệ thống multilib. Tôi giả sử tôi muốn "64", nhưng sau đó "32" và "x32" là gì? Tôi bối rối về những gì tôi cần làm ở đây.

Emerge đang hét rất nhiều về xung đột vị trí và chúng dường như có liên quan đến "ABI_X86" (Tôi quên chính xác các lỗi, nhưng tôi nhớ một lỗi là zlib).

Vì vậy, có tài liệu "chính thức" ABI_X86nào về việc sử dụng nó là gì không?

Từ chủ đề tôi liên kết, tôi tìm thấy trang này: http : //k Richer.org/j Joomla / index.php / en / blog / liste / 29-transition-of-emul-packages-to-true-multilib , nhưng tôi muốn để biết những gì tôi đang làm trước khi tôi đi từ khóa một loạt các công cụ và chỉnh sửa của tôi make.conf.

PS Tôi có hầu hết các gói "ứng dụng mô phỏng / emul-linux-x86" (những gói mà tôi dường như cần vào thời điểm đó) trong tệp "pack.keywords" của mình.

Tôi phải tiết lộ rằng tôi có ít kinh nghiệm sử dụng multilib-build.eclassmultilib trong Gentoo.

ABI_X86là một USE_EXPANDbiến số; thiết lập ABI_X86="32 64"hoặc USE="abi_x86_32 abi_x86_64"là tương đương. Cài đặt mặc định của ABI_X86, kể từ khi viết bài này (2013-09-09), đối với default/linux/amd64/13.0cấu hình dường như chỉ là ABI_X86=64.

Biến này kiểm soát hỗ trợ multilib rõ ràng trong các ebuild sử dụng multilib-build.eclasscách thức multilib giống như Gentoo hơn so với phương thức ban đầu.

Phương thức ban đầu mà các thư viện 32 bit sẽ được cài đặt trong Gentoo là thông qua các ảnh chụp nhanh nhị phân có tên app-emulation/emul-linux-*. Mỗi gói nhị phân mô phỏng này chứa toàn bộ các thư viện 32 bit được một số nhà phát triển Gentoo biên soạn cho bạn. Bởi vì mỗi cái cài đặt một bó các thư viện phải được phối hợp với nhau, việc theo dõi các phụ thuộc của các ebuild chỉ có 32 bit là khó hơn. Ví dụ: nếu bạn cần 32 bit media-libs/alsa-libtrên hệ thống 32 bit, bạn chỉ cần cài đặt media-libs/alsa-lib, nhưng trên hệ thống multilib 64 bit, bạn phải khám phá rằng app-emulation/emul-linux-soundlibscài đặt đó , trong số các thư viện khác, phiên bản 32 bit media-libs/alsa-lib. Ngoài ra, Gentoo dev xây dựng một gói nhị phân như vậy phải thực hiện công việc tìm ra các quirks multilib và buildsystem của mỗi góicủa các thư viện đi kèm trong gói ảnh chụp nhanh, khiến việc bảo trì khó khăn hơn. Và, quan trọng nhất, việc cung cấp các gói nhị phân là tùy chọn chính thức duy nhất để sử dụng multilib trong Gentoo đi ngược lại với tinh thần của Gentoo. Bạn nên có quyền tự biên dịch mọi thứ !

Việc multilib-build.eclasstránh xa hành vi này bằng cách giúp các ebuild riêng lẻ cài đặt cả phiên bản 32 bit và 64 bit. Điều này sẽ cho phép, ví dụ, winechỉ cần chỉ định các phụ thuộc trực tiếp với các gói mà nó cần thay vì cần phải kéo app-emulation/emul-linux-*các gói. Như ssuominen đề cập trong chủ đề diễn đàn mà bạn tham chiếu :

= app-emulation / emul-linux-x86-xlibs-20130224-r1 là gói trống không có tệp vì các tệp đến trực tiếp từ x11-libs /

(Lưu ý rằng -r1từ đó đã được đổi tên thành -r2) Cuối cùng, app-emulation/emul-linux-x86-xlibsbản thân sẽ có thể được giảm xuống như các gói 32-bit chỉ thích hợp phụ thuộc trực tiếp vào các gói đúng ở x11-libsđó, với multilib-build.eclasssự giúp đỡ của, cung cấp các libs 32-bit cần thiết. Đây là nơi ABI_X86đi vào chơi. Bất kỳ multilib-build.eclassgói -enabled đạt ít nhất là sử dụng USE flag mới abi_x86_32và abi_x86_64và có lẽ abi_x86_x32. Sử dụng các EAPI=2phụ thuộc USE kiểu , các gói có thể phụ thuộc vào các phiên bản 32 bit của các gói khác. Nếu x11-libs/libX11được xuất hiện trong khi đó ABI_X86="32 64", thì nó sẽ được cài đặt với cờ USE abi_x86_32và cờ abi_x86_64USE. Nếu một gói đồ họa cụ thể cần phiên bản 32 bit libX11, nó có thể chỉ địnhx11-libs/libX11[abi_x86_32]trong sự phụ thuộc của nó. Bằng cách này, nếu bạn cố gắng xuất hiện gói đồ họa này và libX11chưa cài đặt lib 32 bit, portage sẽ từ chối. multilib-build.eclasscũng là phổ quát và tương thích với các hệ thống 32 bit: cài đặt gói đồ họa tương tự này trên hệ thống 32 bit sẽ luôn hoạt động vì không thể cài đặt libX11mà không cài đặt abi_x86_32hữu ích. Điều này giải quyết vấn đề cần phải phụ thuộc vào app-emulation/emul-linux-x86-xlibskhi nào trên hệ thống multilib và trực tiếp trên x11-libs/libX11hệ thống chỉ có 32 bit. Chúng tôi đang mở đường cho việc có các phụ thuộc liên gói sạch hơn và hợp lý trên các hệ thống multilib. =app-emulation/emul-linux-x86-xlibs-20130224-r2tồn tại như một trung gian cho phép mọi gói cũ được sử dụng để phụ thuộc vào app-emulation/emul-linux-x86-xlibsviệc không biết cách phụ thuộc trực tiếp vào, ví dụ, x11-libs/libX11[abi_x86_32]vẫn hoạt động.=app-emulation/emul-linux-x86-xlibs-20130224-r2đảm bảo rằng các thư viện 32 bit tương tự tồn tại /usr/lib32như thể =app-emulation/emul-linux-x86-xlibs-20130224đã được cài đặt, nhưng thực hiện theo cách Gentoo bằng cách xây dựng các thư viện 32 bit này thông qua các phụ thuộc thay vì cung cấp gói nhị phân. Nó hoạt động giống như các gói trong virtualdanh mục theo cách này: nó không cài đặt bất cứ thứ gì, chỉ phụ thuộc "chuyển tiếp" cho các ebuild hiện có.

Chúng ta đã thấy cách multilib-build.eclassmở đường cho sự phụ thuộc sạch hơn vào các hệ thống multilib. Bất kỳ gói nào có ABI_X86tùy chọn (tương tự như nói nó có abi_x86_*useflags) đã cài đặt phiên bản 32 bit của chính nó nếu bạn đã chỉ định USE=abi_x86_32/ ABI_X86=32. Làm thế nào để nó hoạt động (ở mức độ khái niệm cao)? Bạn có thể đọc ebuild chính nó. Về cơ bản, ý tưởng này giống như các ebuild python hoặc ruby ​​có tùy chọn tự cài đặt cho nhiều phiên bản của python và ruby ​​cùng một lúc. Khi một ebuild kế thừa multilib-build.eclass, nó lặp lại ABI_X86 và thực hiện từng bước của quá trình giải nén, biên dịch và cài đặt cho mỗi mục trong ABI_X86. Kể từ portage đi qua tất cả các giai đoạn ebuild như src_unpack(), src_compile()và src_install()(và những người khác) theo thứ tự và chỉ một lần, cácmultilib-build.eclass(hiện tại, với sự trợ giúp của multibuild.eclass), việc sử dụng sẽ tạo một thư mục cho mỗi giá trị khác nhau của ABI_X86. Nó sẽ giải nén một bản sao của các nguồn cho mỗi thư mục này. Từ đó, mỗi thư mục này bắt đầu phân kỳ khi mỗi mục tiêu là một ABI cụ thể. Thư mục cho ABI_X86=32sẽ ./configure --libdir=/usr/lib32chạy với FLAGS nhắm mục tiêu 32 bit (ví dụ: CFLAGS=-m32xuất phát từ CFLAGS_x86 envvar của cấu hình multilib (lưu ý: cấu hình portage chủ yếu đề cập đến ABI_X86 = 32 là ABI = x86 và ABI_X86 = 64 là ABI = amd64). Trong thời giansrc_install()pha, tất cả các ABI được biên dịch khác nhau được cài đặt trên nhau để khi bất kỳ tệp nào có cả phiên bản 32 bit và 64 bit, ABI bản địa sẽ thắng (ví dụ: một ebuild cài đặt cả thư viện và tệp thực thi trong PATH sẽ chỉ cài đặt 64 -bit thực thi vào PATH nhưng bao gồm cả thư viện 32 bit và 64 bit). Tổng hợp: khi bạn thiết lập ABI_X86="32 64"trong make.conf, bất kỳ gói mà hỗ trợ multilib-build.eclasssẽ mất khoảng gấp đôi so với khối lượng công việc (Tôi không nói rằng thời gian ;-)) để biên dịch vì nó đang được xây dựng một lần cho mỗi ABI và kết quả trong thư viện 32-bit trong /usr/lib32.

Tôi không biết có tài liệu chính thức ABI_X86nào chưa hoặc tình trạng chi tiết của nó. Ebuilds sử dụng multilib-build.eclassdường như không ổn định cho đến nay. Bạn có thể làm theo các hướng dẫn tại blog bạn đã liên kết để bắt đầu trải nghiệm và thử nghiệm ABI_X86nếu bạn hiểu sự khác biệt giữa app-emulation/emul-linux-x86-xlibs-20130224và multilib kiểu mới app-emulation/emul-linux-x86-xlibs-20130224-r2. Nhưng, nếu bạn ổn với gói nhị phân kiểu cũ, tôi nghĩ rằng nó app-emulation/emul-linux-x86-xlibs-20130224vẫn hoạt động. Bạn sẽ chỉ cần phải di chuyển đến -r2nếu bạn sử dụng bất kỳ gói mà trực tiếp phụ thuộc vào của gói khác abi_x86_32useflag (ví dụ, app-emulation/emul-linux-x86-xlibs-20130224và x1-libs/libX11[abi_x86_32]không thể cùng tồn tại bởi vì họ có thể cả cài đặt cùng một thư viện để /usr/lib32, cụ thể là /usr/lib32/libX11.so.6). Một cách nhanh chóngnhìn vào wine-1.7.0.ebuildgợi ý cho tôi rằng nó không cần -r2.

Ngoài ra còn có abi_x86_x32 (nó không giống với abi_x86_32) sử dụng cờ. Đây là thử nghiệm và dự định xây dựng các ứng dụng bán 64 bit. Sự khác biệt duy nhất là họ có con trỏ 4byte. Điều này giới hạn việc sử dụng bộ nhớ ở 4GiB và giảm chi phí trong hầu hết các trường hợp, trong khi cho phép sử dụng tất cả các hướng dẫn 64 bit.

Hiện tại tình hình là địa ngục thực sự. Vấn đề dường như là nhiều gói thuộc loại "nửa mặt nạ" ... Tôi không biết thuật ngữ chính xác, nhưng có vẻ như một số gói được từ khóa "~ amd64" với "abi_x86_32" sử dụng cờ và "amd64" mà không có sử dụng cờ ... Kết quả là, trong quá trình cập nhật của tôi, tôi kích hoạt "abi_x86_32" nhưng emerge vẫn cài đặt các gói với ABI_X86 = "(64) (-32)" trừ khi tôi thêm "~ amd64" cho mỗi gói như vậy. Và nếu nó được kéo như một phụ thuộc thay vì xuất hiện trực tiếp, thì không có lời đề nghị nào cho autounmask-write mà thay đổi - xuất hiện chỉ cho bạn biết nó không thể đáp ứng sự phụ thuộc cho gói đó với cờ sử dụng "abi_x86_32" cần thiết. Vì vậy, tôi phải thêm từng gói một vào gói.keywords với "~ amd64". Đó là rất nhiều công việc thủ công ... Và phiên bản gói nào tôi nên làm điều đó? Tôi không thể nói với nó những gì tôi thực sự muốn, cụ thể là "đối với các phiên bản được đánh dấu là" amd64 "mà không sử dụng cờ đó". Tôi có thể đặt phiên bản mới nhất cụ thể mà tôi thấy bây giờ và do đó làm phức tạp các bản cập nhật trong tương lai của nó hoặc đặt trong tất cả các phiên bản và sau đó có thể cài đặt các phiên bản không được đánh dấu ổn định ngay cả đối với 64 bit ...

Thông tin liên quan gián tiếp: Cho đến ngày hôm nay, hệ thống máy tính để bàn KDE hoàn chỉnh trên systemd có thể được biên dịch theo cách đa cấp thuần túy (không có gói mô phỏng). Vấn đề duy nhất bây giờ là gói trình điều khiển nvidia độc quyền, nhưng điều này có thể được giải quyết bằng cách sử dụng mã nguồn mở ngay bây giờ.

Cách bắt đầu điểm (các liên kết khác có ở đó): https://forums.gentoo.org/viewtopic-t-985380-highlight-.html

Trạng thái chuyển đa cấp Gentoo https://wiki.gentoo.org/wiki/Multilib_porting_status