Как добавить разделяемые библиотеки в проект

Если либа использует pkg-config (99% пакетов из стандартной поставки любого дистрибутива), то тебе надо использовать макрос PKG_CHECK_MODULES в configure.ac.

Вот пример подключения glib (с указанием минимальной требуемой версии):

GLIB_REQUIRED=2.31.13
PKG_CHECK_MODULES(GLIB,[glib-2.0 >= GLIB_REQUIRED])

Советую держать под рукой исходники нескольких небольших проектов с configure.ac/Makefile.am. Там ответы на все вопросы (делать все по аналогии). Это, кстати, касается любого инструментального средства.

Вот еще хороший мануал по autotools: Autotools Mythbuster (no-nonsense guide to Autotools).

Забыл, флаги надо-таки руками подсунуть компилятору:

AC_SUBST(GLIB_LIBS)
AC_SUBST(GLIB_CFLAGS)

А скажите, как по вашему, почему до сих пор некоторые проекты используют autotools? Ведь очевидно, что даже корявый cmake удобнее и читабельнее. Возможно мне кажется, что это очевидно из-за моего плохого знания и autotools, и cmake.

p.s. Мне действительно интересно мнение человека, который разбирается в теме.

это в компетенции autoconf, а не automake

либы добавляются в configure.ac

например так:

AC_CHECK_LIB([sqlite3], [sqlite3_open], [], [AC_MSG_ERROR(["libsqlite3 not found"])])

autotools - стандарт де-факто для свободного софта

вот тебе ссылка на официальный мануал

http://www.gnu.org/software/autoconf/manual/autoconf.html#Libraries

autotools - стандарт де-факто для свободного софта

Это не аргумент. Тем более, что много больших проектов перешло на cmake.

Речь не об удобстве разработчика. Важно, чтобы пользователь имел унифицированный способ управлять установленными пакетами, и на сегодняшний день, pkg-config это стандарт. Т.е. даже если делать все на cmake, то иметь *.pc файлы все равно нужно. В конце концов, не такой уж этот autotools и корявый (в cmake проектах шаг влево/вправо - и надо городить ужасные костыли, а для autoconf почти всегда есть гибкое решение).

Где-то читал обьяснение, что auto в названиях autoconf/automake - это автоматическое решение проблем на стороне пользователя, но никак не упрощение жизни разработчиков.

Спасибо. Пожалуй выделю время на более детальное изучение автотулзов.

Точно так же лет 15 назад говорили про sendmail. Слава п-треку, его уже закопали практически везде.

Советую держать под рукой исходники нескольких небольших проектов с configure.ac/Makefile.am. Там ответы на все вопросы (делать все по аналогии).

Вся суть autotools

Вся суть autotools

Вся суть программирования.

Делаю вот так:

PKG_CHECK_MODULES(LIBZMQ,[libzmq])
AC_SUBST(LIBZMQ_CFLAGS)
AC_SUBST(LIBZMQ_LIBS)

а pkg-config --libs libzmq выдаёт результат?

Так вот

AC_CHECK_LIB([libzmq],[],[AC_MSG_ERROR(["libzmq not found"])])

После изменений в configure.ac/Makefile.am надо делать autoreconf (пересоздать configure/Makefile.in/Makefile).

Разве такие либы называют «разделяемые»? (Shared). Вроде, нет. Это просто статически линкуемые либы, .a.

да, и config.log приложить сюда после запуска ./configure в случае ошибок

Сделал, вот лог, с виду никаких ошибок

$ ./configure 
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make sets $(MAKE)... (cached) yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBOSMOCORE... yes
checking for LIBOSMOVTY... yes
checking for LIBOSMOGSM... yes
checking for LIBOSMOCODEC... yes
checking for gps_waiting in -lgps... no
checking for  in -llibzmq... no
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating src/Makefile
config.status: creating src/common/Makefile
config.status: creating src/misc/Makefile
config.status: creating src/mobile/Makefile
config.status: creating include/Makefile
config.status: creating include/osmocom/Makefile
config.status: creating include/osmocom/bb/Makefile
config.status: creating include/osmocom/bb/common/Makefile
config.status: creating include/osmocom/bb/misc/Makefile
config.status: creating include/osmocom/bb/mobile/Makefile
config.status: creating Makefile
config.status: executing depfiles commands

$ autoreconf 
configure.ac:4: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated.  For more info, see:
configure.ac:4: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
src/common/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
src/misc/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
src/misc/Makefile.am:7: warning: source file '../common/main.c' is in a subdirectory,
src/misc/Makefile.am:7: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
src/misc/Makefile.am:13: warning: source file '../common/main.c' is in a subdirectory,
src/misc/Makefile.am:13: but option 'subdir-objects' is disabled
src/misc/Makefile.am:8: warning: source file '../common/main.c' is in a subdirectory,
src/misc/Makefile.am:8: but option 'subdir-objects' is disabled
src/misc/Makefile.am:11: warning: source file '../common/main.c' is in a subdirectory,
src/misc/Makefile.am:11: but option 'subdir-objects' is disabled
src/misc/Makefile.am:11: warning: source file '../../../gsmmap/geo.c' is in a subdirectory,
src/misc/Makefile.am:11: but option 'subdir-objects' is disabled
src/misc/Makefile.am:9: warning: source file '../common/main.c' is in a subdirectory,
src/misc/Makefile.am:9: but option 'subdir-objects' is disabled
src/mobile/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')

checking for  in -llibzmq... no

Как-то неправильно использовал макрос, autoconf решил что надо собрать без поддежки zeromq.

во-первых, это не тот лог, ты приложил выхлоп ./configure, а я говорил про файлик config.log, который создаётся в директории, где был запущен ./configure

во-вторых,

checking for  in -llibzmq... no

у тебя ошибка здесь

AC_CHECK_LIB([libzmq],[],[AC_MSG_ERROR(["libzmq not found"])])

AC_CHECK_LIB([zmq],[здесь какой-нибудь символ из библиотеки], [],[AC_MSG_ERROR(["libzmq not found"])])

префикс lib лишний, и вторым параметром идёт какой-нибудь экспортируемый символ из этой библиотеки, пойдёт любая функция, которая есть во всех подходящих версиях

советую таки прочитать мануал autoconf-а целиком :)

Делал как советовали выше

PKG_CHECK_MODULES(LIBZMQ,[zmq])
AC_SUBST(LIBZMQ_CFLAGS)
AC_SUBST(LIBZMQ_LIBS)

checking for LIBZMQ... no
configure: error: Package requirements (zmq) were not met:

No package 'zmq' found

fix:

PKG_CHECK_MODULES(LIBZMQ, zmq)

если не поможет — открываешь config.log, и смотришь что произошло.

AC_CHECK_LIB без PKG_CHECK_MODULES(LIBZMQ,[zmq]) пробовал?

Так, интересное наблюдение, при вот таком

PKG_CHECK_MODULES(LIBZMQ,libzmq)
AC_SUBST(LIBZMQ_CFLAGS)
AC_SUBST(LIBZMQ_LIBS)

$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make sets $(MAKE)... (cached) yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBOSMOCORE... yes
checking for LIBOSMOVTY... yes
checking for LIBOSMOGSM... yes
checking for LIBOSMOCODEC... yes
checking for LIBZMQ... yes
checking for gps_waiting in -lgps... no
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating src/Makefile
config.status: creating src/common/Makefile
config.status: creating src/misc/Makefile
config.status: creating src/mobile/Makefile
config.status: creating include/Makefile
config.status: creating include/osmocom/Makefile
config.status: creating include/osmocom/bb/Makefile
config.status: creating include/osmocom/bb/common/Makefile
config.status: creating include/osmocom/bb/misc/Makefile
config.status: creating include/osmocom/bb/mobile/Makefile
config.status: creating Makefile
config.status: executing depfiles commands

в Makefile.am либы и инклуды подключил?

WTF?! Нужно еще и в Makefile.am пихать? Каким образом, и нафиг тогда этот configure.ac? Если б были проблемы с инклудами, ошибка была б другой.

Да.вот так вот

AC_CHECK_LIB([zmq],[zmq_socket], [],[AC_MSG_ERROR(["libzmq not found"])])

прописываю читать туториал по автотулсам, хотя бы хеллоу ворлд.

autotools - стандарт де-факто для свободного софта

Разумеется, нет. Если вы не в курсе, стандарт де-факто - это не то что накопилось за десятки лет, а то что выбирают для новых проектов сейчас. И сейчас это, например, git и cmake, несмотря на мёртвый груз subversion и autocrap. Ну и да, думать вы должны не о стандартах а об удобстве пользователей, мантейнеров и контрибуторов, а autotools, как известно, антоним удобства.

штандарно, перешимо

windows - стандарт де-факто для десктопного софта

ну я вот использую subversion и autotools для новых проектов, и ничего, доволен :) И как раз autotools удобнее для майнтейнеров и пользователей (которые его осилили), даёт им больше гибкости. Как уже сказали выше, autotools не для удобства разработчиков, а для пользователей

думать вы должны не о стандартах

это очень плохая идея, не думать о стандартах. Практически во всех системах сборки пакетов для разных дистрибутивов (как минимум, в .deb, пакетах и портах FreeBSD, в ебилдах генты) autotools поддерживаются из коробки с минимальными усилиями, а для остальных велосипедов приходится извращаться

стандарт де-факто - это не то что накопилось за десятки лет, а то что выбирают для новых проектов сейчас

А вот и хипсторы набежали. Все дискусии об удобстве системы сборки бессмысленны, пока крупные проекты (gnu, freedesktop, gnome) не собираются ничего менять.

Иногда натыкаюсь на то, как твои единомышленники пропихивают cmake в очередной опен-сорц проект (таким образом внося путаницу, оставляя сразу две системы сборки), но забывают поддерживать в актуальном состоянии. Получаем, после внесения сколь-нибудь значимых изменений все тупо летит к х*** перестает собираться через cmake.

Кратко: все эти телодвижения только путают людей (хотя, конечно, были случаи успешной миграции open-source проектов с ужасных autotools).

А скажите, как по вашему, почему до сих пор некоторые проекты используют autotools?

Вариант а) им неохота что-то новое изучать, изначально проект был на автотулзах. Это нормальный вариант. Вариант б) они перебрали упорину и поэтому новый проект тоже на автотулзах пилят.

И как раз autotools удобнее для майнтейнеров и пользователей (которые его осилили), даёт им больше гибкости. Как уже сказали выше, autotools не для удобства разработчиков, а для пользователей

Вас ввели в заблуждение. Я как майнтейнер нескольких портов FreeBSD могу однозначно сказать что autotools почти всегда требует не просто указания пачки ключей и переменных окружения но грубокого патчинга, тогда как cmake работает из коробки.

Практически во всех системах сборки пакетов для разных дистрибутивов (как минимум, в .deb, пакетах и портах FreeBSD, в ебилдах генты) autotools поддерживаются из коробки с минимальными усилиями, а для остальных велосипедов приходится извращаться

По крайней мере про порты FreeBSD опять ложь. cmake там поддерживается не хуже autocrap, и, что характерно, кода для его поддержки понадобилось раз в 10 меньше (а с autotools чего стоит хотя бы война с libtool).

А вот и хипсторы набежали.

Разве хипстеры - это не меньшинство, любящее всякие древние штуки типа плёночных фотоаппаратов? Ну так это как раз поклонники autotools и есть.

Все дискусии об удобстве системы сборки бессмысленны, пока крупные проекты (gnu, freedesktop, gnome) не собираются ничего менять.

Напротив, эти мамонты никого не волнуют, и не будут никуда переходить потому что слишком жирные чтобы совершать резкие движения, да и накопили все возможные костыли для сборки на всех современных системах (пройти через что ни одному новому проекту я никогда не пожелаю).

В то же время, напомню про KDE и сотни других крупных проектов, включая, например, mariadb, blender, ogre3d, brlcad и почти все достойные внимания свободные игры. Да даже фундаментальная libpng на cmake.

Иногда натыкаюсь на то, как твои единомышленники пропихивают cmake в очередной опен-сорц проект

«Мои единомышленники» всего лишь хотят собрать проект без геморроя, это плохо? При том что autocrap этого обеспечить не может и не сможет, если проект не обладает теми же ресурсами что упомянутые gnu, freedesktop и gnome. Две системы сборки это действительно нехорошо, но честно говоря я не видел чтобы после введения cmake старая система сборки продержалась больше месяца.

Кратко: все эти телодвижения только путают людей (хотя, конечно, были случаи успешной миграции open-source проектов с ужасных autotools).

Для начала, речь идёт о выборе системы для нового проекта.