2011-11-01 34 views
17

Trang này - http://labs.qt.nokia.com/2011/10/28/rpath-and-runpath/ - nói về trình tự khám thư viện trong ld.so:sử dụng RPATH chứ không phải RUNPATH?

Unless loading object has RUNPATH: 
    RPATH of the loading object, 
     then the RPATH of its loader (unless it has a RUNPATH), ..., 
     until the end of the chain, which is either the executable 
     or an object loaded by dlopen 
    Unless executable has RUNPATH: 
     RPATH of the executable 
LD_LIBRARY_PATH 
RUNPATH of the loading object 
ld.so.cache 
default dirs 

Và sau đó đề nghị:

Khi bạn gửi mã nhị phân, hoặc sử dụng rPath và không RUNPATH hoặc đảm bảo LD_LIBRARY_PATH được đặt trước khi chúng được chạy.

Vì vậy, sử dụng RPATH với RUNPATH là xấu vì RUNPATH loại-of hủy RPATH nạp năng động để gián tiếp không hoạt động như mong đợi? Nhưng tại sao sau đó RPATH bị phản đối vì lợi ích của RUNPATH?

Ai đó có thể giải thích tình huống này không?

Trả lời

13

Khi bạn gửi một tệp nhị phân, tốt nhất là cung cấp phương tiện cho người dùng để chứa nhị phân cho các chi tiết cụ thể của hệ thống của họ, trong số những thứ khác, điều chỉnh đường dẫn tìm kiếm thư viện.

Một người sử dụng nói chung có thể tinh chỉnh LD_LIBRARY_PATH/etc/ld.co.conf, cả hai đều là có độ ưu tiên thấp hơn DT_RPATH, tức là bạn không thể ghi đè lên những gì là hardcoded trong nhị phân, trong khi đó nếu bạn sử dụng DT_RUNPATH thay vào đó, người dùng có thể ghi đè bằng LD_LIBRARY_PATH .

(FWIW, tôi nghĩ ld.so.conf cũng phải được ưu tiên hơn DT_RUNPATH, nhưng, dù sao, ít nhất chúng tôi cũng có LD_LIBRARY_PATH).

Ngoài ra, tôi thật sự không đồng ý với đề xuất ở trên để sử dụng DT_RPATH. IMO, tốt nhất là sử dụng nether DT_RPATH không phải DT_RUNPATH trong các tệp nhị phân được phân phối.

trừ

bạn tàu tất cả thư viện phụ thuộc của bạn với thực thi của bạn và muốn đảm bảo rằng mọi thứ JustWork (tm) sau khi cài đặt, trong trường hợp này sử dụng DT_RPATH.

+1

vấn đề là, RUNPATH được đề xuất trên RPATH và RPATH không được dùng nữa, nhưng RUNPATH hiện không được tất cả các hệ thống hỗ trợ. vì vậy những gì tôi làm ** ngày hôm nay ** để làm cho ứng dụng hoạt động? như hiển thị bài viết Qt, khi sử dụng các plugin, bạn nên sử dụng RPATH nhiều hơn RUNPATH. Vì vậy, toàn bộ tình huống rất khó hiểu ở đây – zaharpopov

+1

@zaharpopov, Cách tiếp cận tốt nhất tôi khuyên bạn nên làm là tạo ra các ứng dụng được tích hợp độc đáo trong nền tảng đích, bao gồm cả những thứ khác, không phân phối các phiên bản cạnh tranh của nền tảng thư viện được chia sẻ *. Tôi nghĩ rằng đây là gốc rễ của vấn đề và hacks và slashes xung quanh 'DT_RPATH' và bạn bè là một nỗ lực ill-hướng cố gắng để phụ bước vấn đề thay vì giải quyết nó. – chill

+1

điều này không đơn giản. với vấn đề Qt là ứng dụng muốn phiên bản mới hơn của lib Qt hơn tồn tại trên hệ thống. một số hệ thống đã lỗi thời Qt SOs, vậy bạn sẽ làm gì sau đó? tôi nghĩ nó có ý nghĩa khi phân phối các SO Qt với bạn nếu bạn cần một phiên bản cụ thể – zaharpopov

10

Câu trả lời của Chill là chính xác; Tôi muốn chỉ đơn giản là thêm một số màu sắc, từ một lần đọc gần đây của nguồn glibc ([master 8b0ccb2], trong 2,17). Để rõ ràng, nếu không tìm thấy thư viện ở vị trí được chỉ định bởi một cấp độ nhất định, cấp độ tiếp theo sẽ được thử. Nếu một thư viện được tìm thấy ở một cấp độ nhất định, tìm kiếm sẽ dừng lại.

động Thư viện Tìm kiếm theo thứ tự:

  1. DT_RPATH trong nhị phân ELF, trừ khi DT_RUNPATH bộ.
  2. mục LD_LIBRARY_PATH, trừ khi setuid/setgid
  3. DT_RUNPATH trong hệ nhị phân mục
  4. /etc/ld.so.cache ELF, trừ khi nodeflib -z cho lúc liên kết
  5. /lib,/usr/lib trừ - z nodeflib
  6. Xong, "không tìm thấy".
4

Nhưng tại sao sau đó rPath bị phản đối ủng hộ RUNPATH?

Khi DT_RPATH được giới thiệu, nó được ưu tiên hơn tất cả các thông số khác. Điều này không thể ghi đè lên đường dẫn tìm kiếm thư viện ngay cả đối với mục đích phát triển. Vì vậy, một tham số khác, LD_RUNPATH, đã được giới thiệu có ưu tiên thấp hơn LD_LIBRARY_PATH.

Chi tiết khác có thể được tìm thấy trong tác phẩm "How to write shared libraries" được viết bởi Ulrich Drepper.

+1

Câu trả lời này giải thích sự cần thiết của 'DT_RUNPATH', nhưng không giải thích tại sao' DT_RPATH' không được chấp nhận. Cả hai đều có cách sử dụng riêng và 'DT_RUNPATH' ngắt' libtool' khi 'LD_LIBRARY_PATH' được sử dụng: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732 – vinc17

Các vấn đề liên quan