Làm thế nào để xây dựng một thư viện được chia sẻ (.so) mà không có đường dẫn phụ thuộc đầy đủ được mã hóa cứng?

Question

Tôi cần phải xây dựng hai thư viện chia sẻ của bên thứ ba, vì vậy các tệp .so của chúng sẽ được các dự án khác sử dụng lại. Tuy nhiên, sau khi xây dựng một trong các thư viện này có chứa đường dẫn mã hóa cứng khác. Đường dẫn này không hợp lệ trên các máy khác và gây cảnh báo liên kết. Làm thế nào tôi có thể ngăn chặn đường dẫn đầy đủ từ được nhúng trong các tập tin .so kết quả?

chi tiết:

Đầu thư viện nguồn: ~/dev/A
nguồn thư viện thứ hai: ~/dev/B

Cả hai đều có configure kịch bản để tạo ra làm cho tập tin. Thư viện B tùy thuộc vào A. Vì vậy, lần đầu tiên tôi xây dựng A:

$ ~/dev/A/configure --prefix=~/dev/A-install 
$ make && make install 

Sau đó, tôi xây dựng B:

$ ~/dev/B/configure --prefix=~/dev/B-install --with-A=~/dev/A-install 
$ make && make install 

Sau đó, tôi muốn tải lên nội dung của ~/dev/A-install và ~/dev/B-install đến máy chủ tập tin của chúng tôi, vì vậy các đội khác và xây dựng máy có thể sử dụng các tệp nhị phân. Nhưng họ nhận được lời cảnh báo mối liên kết khi họ cố gắng sử dụng B:

/usr/bin/ld: warning: libA.so.2, needed by /.../deps/B/lib/libB.so, not found (try using -rpath or -rpath-link) 

Khi tôi chạy ldd libB.so nó mang lại:

... 
libA.so.2 => /home/alex/dev/A-install/lib/libA.so.2 

Rõ ràng con đường này chỉ tồn tại trên máy tính của mình và không thể được tìm thấy trên các máy khác.

Tôi làm cách nào để xóa đường dẫn được mã hóa đầy đủ khỏi libB.so?

Cảm ơn.

Answer 1

Bạn phải sử dụng --prefix giá trị mà sẽ có hiệu lực trong thời gian chạy môi trường cho cả gói!

Hơn bạn ghi đè prefix hoặc DESTDIR (prefix thay thế tiền tố, DESTDIR được thêm vào trước, nhưng hoạt động đáng tin cậy hơn) khi tạo dòng lệnh khi cài đặt. Giống như:

~/dev/A$ ./configure 
~/dev/A$ make 
~/dev/A$ make install prefix=~/dev/A-install 
~/dev/B$ ./configure --with-A=~/dev/A-install 
~/dev/B$ make 
~/dev/B$ make install prefix=~/dev/B-install 

hoặc (được ưa thích và là cách tất cả các công cụ gói xây dựng sử dụng nó):

~/dev/A$ ./configure 
~/dev/A$ make 
~/dev/A$ make install DESTDIR=~/dev/A-install 
~/dev/B$ ./configure --with-A=~/dev/A-install/usr/local 
~/dev/B$ make 
~/dev/B$ make install prefix=~/dev/B-install 

vì cách này bạn đang cài đặt để ~/dev/A-install/$prefix, vì vậy với mặc định tiền tố ~/dev/A-install/usr/local. Ưu điểm của tùy chọn sau này là, nếu bạn xác định lại một số đường dẫn cài đặt cụ thể mà không tham chiếu đến tiền tố (nói --sysconfdir=/etc), DESTDIR sẽ vẫn được thêm vào trước, trong khi nó sẽ không bị ảnh hưởng bởi prefix.

Answer 2

Có lẽ bằng cách sử dụng tùy chọn -rpath và -soname để ld có thể giúp (giả sử một binutils hoặc gói binutils.gold cho ld trên một hệ thống Linux gần đây)?

Answer 3

-Wl,-rpath,~/deps/A/lib:~/deps/B/lib:~/dev/MyApp/bin 

Tùy chọn trình liên kết này có trách nhiệm lưu đường dẫn bên trong thư viện. Bạn cần bằng cách nào đó để loại bỏ điều này.

Xem với ./configure --help nếu có một số tùy chọn có thể ảnh hưởng đến điều này. Một tùy chọn khác là chỉnh sửa thủ công makefile và xóa tùy chọn này.

== edit2 == Một điều nữa

-L~/deps/A/lib -L~/deps/B/lib ~/deps/A/lib/libA.so ~/deps/B/lib/libB.so 

Nếu libA.so và libB.so không có SONAME, liên kết chúng như "~/DEPS/A/lib/libA.so" cũng sẽ tiết kiệm đường dẫn. Soname được đặt bằng cách sử dụng tùy chọn liên kết -Wl,-soname,<soname> khi xây dựng thư viện được chia sẻ.

Nếu soname được đặt trong thư viện được chia sẻ, liên kết nó bằng cách sử dụng "~/deps/A/lib/libA.so" biểu mẫu là ok.

Giống như Jan đã đề cập trong nhận xét, cách tốt hơn là sử dụng "-Llibrary/path -llibrary_name" không có rpath.

-L~/deps/A/lib -L~/deps/B/lib -lA -lB 

Answer 4

Tôi vừa mới bắt gặp suy nghĩ rằng tôi có cùng một vấn đề. Không có câu trả lời nào ở trên giúp ích cho tôi. Bất cứ khi nào tôi đã cố gắng

ldd libB.so 

tôi sẽ nhận được trong đầu ra:

libA.so.1 => /home/me/localpath/lib/libA.so.1.0 

và vì vậy tôi nghĩ rằng tôi đã có một con đường cứng. Hóa ra là tôi đã quên tôi đã đặt LD_LIBRARY_PATH cho thử nghiệm cục bộ. Thanh toán bù trừ LD_LIBRARY_PATH nghĩa là ldd tìm thấy thư viện được cài đặt đúng trong/usr/lib/

Answer 5

Khi tôi chạy ldd libB.so nó mang lại:

libA.so.2 =>/home/alex/dev/A-install/lib/libA.so.2

Giải pháp cấp thấp cho vấn đề này là sử dụng tùy chọn "-soname = libA.so" khi bạn liên kết thư viện libA.so. Bằng cách có SONAME được định nghĩa cho một đối tượng được chia sẻ, trình liên kết sẽ không nhúng đường dẫn tuyệt đối khi liên kết với đối tượng được chia sẻ đó.

OP đang sử dụng "định cấu hình", vì vậy đây không phải là giải pháp dễ thực hiện trừ khi anh sẵn sàng đi vào ruột của Makefile được tạo bởi tập lệnh cấu hình.