Tại sao phải tự động/tự động liên kết dự án với thư viện được cài đặt thay vì thư viện phát triển cục bộ?

Question

Tôi đang tạo thư viện libgdata có một số kiểm tra và chương trình không được cài đặt. Tôi đang chạy vào vấn đề mà một khi tôi đã cài đặt các thư viện một lần, các chương trình dường như được liên kết đến các phiên bản cài đặt và không phải là phiên bản địa phương trong ../src/libgdata.la nữa.

Điều gì có thể gây ra điều này? Tôi đang làm điều gì đó khủng khiếp sai?

Đây là những gì test/Makefile.am của tôi trông giống như:

INCLUDES = -I$(top_srcdir)/src/ -I$(top_srcdir)/test/ 

# libapiutil contains all of our dependencies! 
AM_CXXFLAGS = $(APIUTIL_CFLAGS) 
AM_LDFLAGS = $(APIUTIL_LIBS) 

LDADD = $(top_builddir)/src/libgdata.la 

noinst_PROGRAMS = gdatacalendar gdatayoutube 

gdatacalendar_SOURCES = gdatacalendar.cc 

gdatayoutube_SOURCES = gdatayoutube.cc 

TESTS = check_bare 

check_PROGRAMS = $(TESTS) 

check_bare_SOURCES = check_bare.cc 

(libapiutil là một thư viện mà có một số công cụ trợ giúp để đối phó với libcurl và libxml ++)

Vì vậy, ví dụ, nếu tôi chạy thử nghiệm mà không cần cài đặt bất cứ thứ gì, mọi thứ đều hoạt động tốt. Tôi có thể thực hiện các thay đổi cục bộ và chúng được các chương trình này thu thập ngay lập tức.

Nếu tôi cài đặt gói, các chương trình này sẽ biên dịch (có vẻ như nó thực sự trông cục bộ cho tiêu đề), nhưng khi tôi chạy chương trình, nó than phiền về các ký hiệu bị thiếu. Theo như tôi có thể nói, nó liên kết với thư viện mới được xây dựng (../src/libgdata.la) dựa trên đầu ra, vì vậy tôi không chắc tại sao điều này lại xảy ra. Nếu tôi loại bỏ các tập tin được cài đặt, các thay đổi cục bộ để src/* được chọn tốt.

Tôi đã bao gồm đầu ra cho gdatacalendar bên dưới.

g++ -DHAVE_CONFIG_H -I. -I.. -I../src/ -I../test/ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT gdatacalendar.o -MD -MP -MF .deps/gdatacalendar.Tpo -c -o gdatacalendar.o gdatacalendar.cc 
mv -f .deps/gdatacalendar.Tpo .deps/gdatacalendar.Po 
/bin/bash ../libtool --tag=CXX --mode=link g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -L/home/altern8/workspaces/4355/dev-install/lib -lapiutil -lcurl -lgssapi_krb5 -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0 -o gdatacalendar gdatacalendar.o ../src/libgdata.la 
mkdir .libs 
g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -o .libs/gdatacalendar gdatacalendar.o -L/home/altern8/workspaces/4355/dev-install/lib /home/altern8/workspaces/4355/dev-install/lib/libapiutil.so /usr/lib/libcurl.so -lgssapi_krb5 /usr/lib/libxml++-2.6.so /usr/lib/libxml2.so /usr/lib/libglibmm-2.4.so /usr/lib/libgobject-2.0.so /usr/lib/libsigc-2.0.so /usr/lib/libglib-2.0.so ../src/.libs/libgdata.so -Wl,--rpath -Wl,/home/altern8/workspaces/4355/dev-install/lib 
creating gdatacalendar 

Trợ giúp. :)

CẬP NHẬT

tôi nhận được các thông điệp sau khi tôi cố gắng để chạy các chương trình lịch khi tôi đã thêm các phương pháp addCommonRequestHeader() đến lớp dịch vụ sau khi tôi đã cài đặt thư viện mà không có phương pháp addCommonRequestHeader().

/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar: 
symbol lookup error: 
/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar: 
undefined symbol: 
_ZN55gdata7service7Service22addCommonRequestHeaderERKSsS4_ 

Đề xuất của Eugene để thử đặt biến số $LD_LIBRARY_PATH không hiệu quả.

CẬP NHẬT 2

tôi đã làm hai bài kiểm tra. Trước tiên, tôi đã làm điều này sau khi thổi đi thư mục dev-install của tôi (--prefix) và trong trường hợp đó, nó tạo ra test/.libs/lt-gdatacalendar. Một khi tôi đã cài đặt thư viện, mặc dù, nó tạo ra test/.libs/gdatacalendar thay thế. Đầu ra của ldd giống nhau cho cả hai với một ngoại lệ:

# before install 
# ldd test/.libs/lt-gdatacalendar 
libgdata.so.0 => /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0 (0xb7c32000) 

# after install 
# ldd test/.libs/gdatacalendar 
libgdata.so.0 => /home/altern8/workspaces/4355/dev-install/lib/libgdata.so.0 (0xb7c87000) 

Điều gì sẽ gây ra điều này để tạo lt-gdatacalendar trong một trường hợp nhưng gdatacalendar trong trường hợp khác?

Kết quả của ldd trên libgdata là:

altern8@goldfrapp:~/workspaces/4355/libgdata$ ldd /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0 
     linux-gate.so.1 => (0xb7f7c000) 
     libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7f3b000) 
     libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dec000) 
     /lib/ld-linux.so.2 (0xb7f7d000) 

Answer 1

Không chắc làm thế nào để làm điều đó trong autoconf, nhưng lệnh cuối cùng có thể cần phải có -L ../ src, vì vậy mối liên kết có thể tìm thấy thư viện mới được xây dựng đầu tiên .

Thử chạy theo cách thủ công lệnh cuối cùng bằng phần bổ sung đó và xem có trợ giúp không.

EDIT: Ok, tôi đoán đã đọc sai, nghĩ rằng nó không liên kết, nhưng bạn đang nói nó liên kết nhưng không chạy?

Nếu trường hợp đó xảy ra, hãy chạy ldd trên tệp nhị phân của bạn và xem nó sẽ như thế nào - những thứ có khả năng được cài đặt (và lỗi thời nhất).

Trong trường hợp này, hãy cài đặt cập nhật libs trước khi chạy hoặc xuất biến LD_LIBRARY_PATH env trước khi chạy.

export LD_LIBRARY_PATH="/path to freshly built libs" 

Answer 2

Tôi biết rằng đối với phụ thuộc để làm việc một cách chính xác, bạn cần phải tham khảo libgdata.la với một đường dẫn tương đối trong LDADD; có thể ảnh hưởng đến tình huống bạn đang mô tả.

Tôi không chắc chắn lý do tại sao. Hành vi bạn mô tả dường như hơi lạ; và có lẽ đáng báo cáo cho các nhà phát triển libtool.

Answer 3

Tôi nghĩ rằng tôi đã sắp xếp điều này.

Vấn đề phải là libtool thấy cờ "-L" trong dòng lệnh trước khi nó nhìn thấy phần "../src/libgdata.so". Trong trường hợp này, nó thực hiện liên kết với "-Wl, -rpath, ..." cho đường dẫn "-L" đó. Nếu đường dẫn đó chứa "libgdata.so", thì nó sẽ luôn được sử dụng, đó là trường hợp ở đây.

Trong trường hợp của tôi, tôi đã sắp xếp lại "prog_LDADD" thích như thế này: "prog_LDADD = $ (top_builddir) /src/my_lib.so $ (DEPENDENCY_LIBS)"

Trong trường hợp của bạn, hãy cố gắng xóa AM_LDFLAGS và viết:

LDADD = $ (top_builddir) /src/libgdata.la $ (APIUTIL_LIBS)

Answer 4

Without -no-cài đặt libtool tạo giấy gói kịch bản và đặt thực thi vào .libs/subdir (liên kết với các thư viện được cài đặt). Việc gọi trình bao bọc làm cho tải/liên kết thực thi của bạn với thư viện cục bộ (chưa được cài đặt) - vì vậy mọi thứ hoạt động tốt, ví dụ: make check không kiểm tra cài đặt nhưng thư viện mới được tạo của bạn.

Trong một số trường hợp (ví dụ: khi gỡ lỗi hoặc giảm dần), bạn không muốn có trình bao bọc đó, nhưng thực thi thực sự được liên kết trực tiếp với thư viện địa phương của bạn. Đối với điều này bạn sử dụng AM_LDFLAGS = -no-install (hoặc chỉ cần đặt nó cho các mục tiêu duy nhất).

Chi tiết here