Почему ссылка autoconf/automake проекта на установленную библиотеку вместо локальной библиотеки разработки?
Я создаю библиотеку libgdata, которая имеет некоторые тесты и не установленные программы. Я столкнулся с проблемой, что, как только я установил библиотеку один раз, программы, похоже, уже больше привязываются к установленной версии, а не к локальной версии в ../src/libgdata.la.
Что может быть причиной этого? Я делаю что-то ужасно неправильно?
Вот как выглядит мой test/Makefile.am:
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 - это еще одна библиотека, которая имеет некоторый вспомогательный материал для работы с libcurl и libxml ++)
Так, например, если я запускаю тесты, не устанавливая ничего, все работает нормально. Я могу внести изменения локально, и они сразу же подбираются этими программами.
Если я установлю пакет, эти программы будут компилироваться (похоже, он действительно выглядит локально для заголовков), но как только я запускаю программу, он жалуется на недостающие символы.
Насколько я могу судить, он связывается с недавно созданной библиотекой (../src/libgdata.la) на основе вывода make, поэтому я не уверен, почему это произойдет. Если я удалю установленные файлы, локальные изменения в src/* будут подобраны просто отлично.
Я включил вывод make для gdatacalendar ниже.
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
Справка.:)
UPDATE
Я получаю следующие сообщения, когда пытаюсь запустить программу календаря, когда я добавил метод addCommonRequestHeader() в класс службы после того, как я установил библиотеку без метода 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_
Предложение Евгения попробовать установить переменную $LD_LIBRARY_PATH не помогло.
ОБНОВЛЕНИЕ 2
Я сделал два теста. Во-первых, я сделал это после того, как удалил каталог dev-install (-prefix), и в этом случае он создает test/.libs/lt-gdatacalendar. Однако, как только я установил библиотеку, он создает вместо него test/.libs/gdatacalendar. Выход ldd одинаковый для обоих с одним исключением:
# 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)
Что может вызвать создание lt-gdatacalendar в одном случае, но gdatacalendar в другом?
Выход ldd в libgdata:
[email protected]:~/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)
Ответы
Ответ 1
Думаю, я это разобрал.
Проблема заключается в том, что libtool видит флаг "-L" в командной строке, прежде чем он увидит часть "../src/libgdata.so". В этом случае он выполняет компоновщик с "-Wl, -rpath,..." для этого пути "-L". Если этот путь содержит "libgdata.so", то он всегда будет использоваться, что здесь и происходит.
В моем случае я перестроил "prog_LDADD", чтобы вот так:
"prog_LDADD = $(top_builddir)/src/my_lib.so $(DEPENDENCY_LIBS)"
В вашем случае попробуйте удалить AM_LDFLAGS и напишите:
LDADD = $(top_builddir)/src/libgdata.la $(APIUTIL_LIBS)
Ответ 2
Не уверен, как это сделать в autoconf, но для окончательной команды может потребоваться -L../src, поэтому компоновщик может сначала найти недавно созданную библиотеку.
Попробуйте вручную запустить последнюю команду с этим дополнением и посмотрите, помогает ли это.
EDIT: Хорошо, я думаю, неправильно понял, думал, что это не ссылка, но вы говорите, что это ссылки, но не работает?
Если это так, запустите ldd в своем двоичном файле и посмотрите, какой из них он забирает - скорее всего, установленные (и устаревшие).
В этом случае либо установите обновленные библиотеки перед запуском, либо экспортируйте переменную en_LIBRARY_PATH env перед запуском.
export LD_LIBRARY_PATH="/path to freshly built libs"
Ответ 3
Я знаю, что для корректной работы зависимостей вам нужно обратиться к libgdata.la с относительным путем в LDADD; возможно, это влияет и на ситуацию, которую вы описываете.
Я не уверен, почему. Поведение, которое вы описываете, кажется немного странным; и, возможно, стоит сообщить разработчикам libtool.
Ответ 4
Без -no-install libtool создает обертки script и помещает исполняемые файлы в .libs/subdir (связанные с установленными библиотеками). Вызов обертки делает вашу исполняемую нагрузку/ссылку с вашей локальной (не установленной) библиотекой - так что все работает нормально, например. make check не тестирует установленную, но вашу недавно выпущенную библиотеку.
В некоторых случаях (например, при отладке или valgrinding) вы не хотите иметь эти обертки, а реальные исполняемые файлы напрямую связаны с вашей локальной библиотекой. Для этого вы используете AM_LDFLAGS = -no-install (или просто установите его для одиночных целей).
Подробнее здесь
