automake - относительные и абсолютные пути к заголовочным файлам

-I$(top_srcdir)/include/func.h -I$(top_srcdir)/include/utils.h -I$(top_srcdir)/include/new.h

Порнография какая-то. Ключ -I принимает в качестве аргумента пути каталогов, а не файлов: -I$(top_srcdir)/include. И всё.

-I$(top_srcdir)/include -I/usr/incdir/dir1 -I/usr/incdir/dir2

Да, если эти каталоги в рабочей директории. А вот «наружу» в упор видеть не хочет, нет оттуда файлов и все тут. Даже ссылки на внешние каталоги сделал из рабочей директории, все одно не видит заголовочные файлы «из-вне»

пути до внешних компонентов принято указывать извне

CFLAGS=-I/path/to/external/headers
LDFLAGS=-L/path/to/external/libs
./configure ...

Давай минимальный нерабочий пример, посмотрим.

Ты втираешь какую-то дичь, просто каталоги, а не файлы – должны работать.

Смотри что у тебя в .h и .c файлах, возможно там ситуация, когда используется условное:

#include <somelib/name.h>

А ты делаешь -I/path_to/somelib вместо -I/path_to

Виноват . Сам накосячил , дело было вечером. Спасибо за науку

Но у меня другая теперь беда.

Один и тот же проект для работы в плагине работы с LDAP компилился раньше старым надежным способом Makefile Потребовалось автоматизировать, в дело пошел automake А он генерирует бинарный файл вдвое больше размером и адреса функций в дампе отличаются. Наверное, из-за этого плагин у программеров не работает. Сейчас используется libtools . В проекте нужно линковать librabbitmq.so , а во всех талмутах не встречаю линкование бинарных библиотек. Причем, явно, что компилятор ее видит, так как если либу удалить, то ругается. Либа лежит среди соурсов.

я делаю так: mylib_LIBADD = $(top_builddir)/src/librabbitmq.so -lpthread -lcrypto

Можно как-то приблизить к оригиналу это произведение? Что я делаю не так?

AUTOMAKE_OPTIONS = foreign subdir-objects

lib_LTLIBRARIES = mylib.la

ACLOCAL_AMFLAGS = -I m4

AM_SUBDIRFLAGS = –enable-subdir-objects FLAGS = -shared -fPIC

mylib_la_SOURCES = …

mylib_la_CFLAGS = …

mylib_la_LDFLAGS = -shared -module -avoid-version

mylib_la_LIBADD = $(top_builddir)/src/librabbitmq.so -lpthread -lcrypto

Добавил AM_CFLAGS = -fPIC - не помогает

Сделай make V=1 в первом случае и во втором и сравни флаги.

вдвое больше размером

Проверь флаги оптимизации, вызов strip и наличие/отсутствие -g флажка при сборке.

make выводит (фрагмент)

/bin/sh ./libtool –tag=CC –mode=link gcc -I ./src/include/ -I ./src/ -I /usr/include/ -I /usr/include/dirsrv/ -I /usr/include/nspr/ -shared -fpic -g -O2 -o mylib.la -rpath /usr/local/lib ./src/mylib_la-err.lo ./src/mylib_la-utils.lo ./src/mylib_la-slapi_post_op.lo -L./src/ -l:librabbitmq.so -lpthread -lcrypto -lpthread -lcrypto

libtool: link: gcc -shared -fPIC -DPIC ./src/.libs/mylib_la-err.o ./src/.libs/mylib_la-utils.o ./src/.libs/mylib_la-slapi_post_op.o -L./src/ -l:librabbitmq.so -lpthread -lcrypto -g -O2 -Wl,-soname -Wl,mylib.so.0 -o .libs/mylib.so.0.0.0

......
ylib_LDADD = -L$(top_builddir)/src -lrabbitmq -lpthread -lcrypto

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

-g

This. Надо в конце делать strip.

Если нужны и отладочные и релизные сборки, запили флаг debug, вот так: ./configure --enable-debug/--disable-debug и в зависимости от того, что у тебя передается, собирай с разными опциями компилятора.

https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Package-... - в помощь.

И еще вот: https://autotools.info/

можно использовать AC_CHECK_LIB https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Libraries.html, тогда configure сам пропишет линковку с либой

Да, до опции -L мы тоже дошли. Хотя ни в одной доке про нее я не нашел. Скомпилили форк клиента рэббита, в нем уже есть AM и AC, и либа рэббита вышла тоже вдвое больше чем у той, что скомпилена с помощью cmake. Видимо, такое свойство у libtools. Отдал программистам, и с ней очереди не заработали. Что ж такого делает libtools, что ее бинарники выходят такими распухшими?

это интересно!

Да, до опции -L мы тоже дошли. Хотя ни в одной доке про нее я не нашел

да ладно вам

$ ./configure --help
........

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help              display this help and exit
........
Some influential environment variables:
  CC          C compiler command
  CFLAGS      C compiler flags
  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
              nonstandard directory <lib dir>
  LIBS        libraries to pass to the linker, e.g. -l<library>
  CPPFLAGS    (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
              you have headers in a nonstandard directory <include dir>
......

Что ж такого делает libtools, что ее бинарники выходят такими распухшими?

зависит от Ваших флагов и флагов проставленных системой, ранее Вам об этом уже писали

но собственно какая разница? в production обычно идут strip-ые, а при разработке больший размер обычно благо, так как даёт больше данных при отладке

либа рэббита вышла тоже вдвое больше чем у той, что скомпилена с помощью cmake

думается это легко объяснить, у cmake поди использовали тип сборки Release https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html, а он подставляет -O3, сравните размеры при сборке Debug

Но зачем?

Autotools это всратое легаси говно, и тебе на самом деле не нужны его 100500 возможностей собирать под древние юниксы из 80х.

Для небольших проектов лучше взять тупо Makefile написать(впрочем как показывает опыт ядра линукс, это годится и для больших). Для чего побольше - м.б. meson+ninja (CMake лучше обходить стороной, это такое же всратое говно как autotools)

У debuild cmake под капотом

Поступило новое распоряжение. Собирать deb-пакет с помощью debuild Нужно использовать librabbitmq-dev для включения в библиотеку mylib.so

В control указываю:

Build-Depends: debhelper (>= 11), librabbitmq-dev, libssl-dev

В Makefile-е

CFLAGS := -Wall -O2 LDFLAGS := -Wl,-rpath,/usr/local/lib -lrabbitmq

…

$(TARGET): $(OBJS) $(CC) $(CFLAGS) -shared -o $@ $^ $(LDFLAGS)

Но получаю ошибку dpkg-shlibdeps: ошибка: информация о зависимостях не найдена для /usr/local/lib/librabbitmq.so.4 (используется debian/…/usr/lib/x86_64-linux-gnu/dirsrv/plugins/mylib.so) Подсказка: проверьте, действительно ли библиотеки из этого пакета.

ii librabbitmq-dev:amd6 0.9.0-0.2 AMQP client library written in C - Dev Files

ii librabbitmq4:amd64

Как указать, что собирать все надо из librabbitmq-dev ?