2010-10-18 8 views
19

Tôi đang làm việc trên một plugin Firefox sử dụng thư viện bên ngoài để hiển thị đồ họa 3D trên trình duyệt.cách liên kết đến lib được chia sẻ từ lib được chia sẻ với đường dẫn tương đối

Vấn đề là tôi muốn plugin sử dụng thư viện bên ngoài được đóng gói kèm theo mà không thay đổi biến số LD_LIBRARY_PATH.
Các thư viện được cài đặt ở vị trí tương đối so với plugin (thư viện được chia sẻ), trong khi thực thi thực tế (tức là trình duyệt) có thể được đặt ở đâu đó hoàn toàn khác.

Một số điều bạn phải biết. Tôi đang thử nghiệm nó trên Ubuntu (không có vấn đề ở phiên bản Windows của plugin) Phụ thuộc của tôi là thư viện OpenSceneGraph và biên dịch tĩnh sẽ làm cho plugin thực sự lớn (không phải là một tùy chọn nếu có một plugin khác)

Hy vọng bạn có thể giúp tôi

Trân trọng.

+2

Điều này có thể hữu ích: http://stackoverflow.com/questions/3015411/shipping-gnu-linux-firefox-plugin-với-chia sẻ-thư viện-cho-cài đặt-với-không –

+0

Thú vị, tôi có thể xác nhận rằng với một chương trình thử nghiệm đơn giản. Nó sử dụng 'dlopen()' để tải một liên kết 'lib1' và' lib1' vào 'lib2' và sử dụng' $ ORIGIN' để tải nó từ một đường dẫn tương đối. Điều này làm việc mà không có vấn đề. –

Trả lời

0

Bạn có thể sử dụng cờ -L trong quá trình biên dịch để chỉ định đường dẫn tương đối trong đó trình liên kết có thể tìm thấy đối tượng được chia sẻ của bạn.

Nếu bạn đã tạo lib của mình, bạn có thể liên kết bằng cách gọi trực tiếp lệnh ld.

Mẹo: Bạn có thể dễ dàng kiểm tra xem một số ký hiệu được xác định trong lib có sử dụng lệnh unix nm hay không. Đây là một cách hữu ích để kiểm tra xem liên kết có được thực hiện tốt hay không.

(Nếu tôi là bạn, tôi sẽ chỉ cần thay đổi temporaly các LD_LIBRARY_PATH như bạn nói trong bài viết của bạn. Tại sao bạn không muốn làm điều này?)

+0

Nó không phải là về mối liên kết tìm kiếm các thư viện, đó là về trình tải tìm kiếm chúng ở một vị trí liên quan đến thư viện hiện đang được tải (plugin). Với các plugin, bạn không thể kiểm soát quá trình host (tức là trình duyệt) được gọi, do đó các biến môi trường sẽ không thực hiện được. Trên OS X '@ loader_path' hiện các trick, trên Linux tôi không biết. –

+0

Ok xin lỗi vì đọc xấu. Có lẽ điều tốt nhất để làm là sử dụng các lệnh ngôn ngữ cụ thể để tải lib khi chạy. Tôi có thể sẽ xóa câu trả lời này vào ngày mai nếu tôi không tìm cách giải quyết vấn đề này đúng cách. – ThR37

+0

Tải động thông thường có những bất lợi lớn khi không có sơ đồ, vì vậy bạn phải giải quyết các ký hiệu theo cách thủ công:/ –

26

Sử dụng tùy chọn rPath khi liên kết và chỉ định 'đặc biệt 'đường dẫn $ ORIGIN.

Ví dụ:

-Wl,-R,'$ORIGIN/../lib' 

Đây là một trang web mà trau chuốt về việc sử dụng $ ORIGIN: http://www.itee.uq.edu.au/~daniel/using_origin/

+5

liên kết bị hỏng (5 tuổi có tôi biết :)) – dashesy

+0

[Máy ​​Wayback] (https: // web.archive.org/web/20130915172134/http://itee.uq.edu.au/~daniel/using_origin/) để giải cứu :) – 865719

+0

Ngoài ra, [có vẻ như] (https://en.wikipedia.org/wiki/Rpath) rằng ['chrpath'] (http://man.devl.cz/man/1/chrpath) và [' patchelf'] (http://man.devl.cz/man/1/patchelf) có thể giúp quá (tôi chưa thử chúng ...) – 865719

-2

Đó là sai lầm khi sử dụng rPath tương đối vì lý do an ninh,

Bạn nên sử dụng chức năng libdl (dlopen, v.v ..)

+3

Nếu thực hiện kém, việc sử dụng rpath chắc chắn có thể gây ra vấn đề, nhưng Linux (và các hệ thống khác) có các biện pháp bảo vệ tích hợp. Ví dụ: trong một số trường hợp nhất định, ld.so sẽ không mở rộng ORIGIN. Ngoài ra, các đường dẫn tương đối là hoàn toàn cần thiết cho các chương trình relocatable; nếu không, bạn sẽ phải cài đặt một gói phần mềm vào một vị trí cố định - ví dụ, buộc phải cài đặt MATLAB vào/usr/share/matlab luôn thay vì một cái gì đó như/opt/matlab, hoặc/usr/local/matlab, v.v. –

+1

Hơn nữa, mọi người có thể đưa ra quyết định sáng suốt về việc liệu có nên sử dụng mở rộng ORIGIN hay không, đặc biệt nếu phần mềm được đề cập là tạo ra riêng của họ và được sử dụng trên phần cứng của riêng họ. –