Пытаюсь разобраться

почему линкуется с so?

Умолчания видимо - gcc с so линкует без особых указаний. Посмотри команду на компоновку и всё поймёшь(ну кроме того, что тебе нужен не autotools, а cmake)

libtool - архаика и кривая мерзость, зачем вы в нём разбираетесь?

main_LDADD = my.a

?

Так там линковка через libtool завязана, команда

libtool: link: g++ -std=c++17 -Wall -Wextra -Wshadow -pipe -O2 -DNDEBUG -o main main.o  -lmy

хз чего там у libtool’a на уме

А какой тогда смысл в libtool’e? Он ведь должен пытаться линковаться с абстракцией .la

не знаю, не использую его)

Я тоже от него не в восторге. Как вы линкуете so либы? Ну можно самому давать флаги вроде -fPIC -shared. Но хз, не уверен (переосимость и всё такое).

тебе нужен не autotools, а cmake

что бы получить ещё большую абстракцию над компилятором. А чем autotools плох? Не осиливается такой синтаксис

AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile
		src/Makefile
		src/tests/Makefile
		src/ee/Makefile])

Вот libtool, какой-то нехороший костыль …

Хм, точно, я и забыл уже. Короч, бери cmake и не парься(там хотя бы вызов компилятора и линкера можно увидеть)

ещё большую абстракцию над компилятором

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

А чем autotools плох?

Под виндой не работает. Щас набегут свидетели cygwin-а и msys, но это работа в cygwin и msys, а не в винде. Ну и дока у cmake лучше

Кастуй Harald, он всё время за этот кошмар топит. Вдруг он в нем еще и разбирается.

Да не, это значительно более абстрактная ерунда. Вот хочу я какие-то отладочные флаги для компилятора, это в принципе не кроссплатформенно. А для автотулзов накостылил

cxx_flags="-O2 -DNDEBUG"
AC_ARG_ENABLE(debug,
		AS_HELP_STRING([--enable-debug], [enable debugging, default: no]),
		[case "${enableval}" in
			yes) cxx_flags="-O0 -ggdb3 -D_GLIBCXX_ASSERTIONS";;
			no)  ;;
			*)   AC_MSG_ERROR([bad value ${enableval} for --enable-debug]) ;;
		esac])
CXXFLAGS=${CXXFLAGS=${cxx_flags}}

Так что знаете, вертел я эту всякую винду. Костылить потом в этом cmake под каждый компилятор.

(libmy.la, libmy.so*)

А статическая библиотека где? Которая libmy.a.

set(OPTS -O2 -DNDEBUG)
if (CMAKE_BUILD_TYPE STREQUAL Debug)
  set(OPTS -O0 -ggdb3 -D_GLIBCXX_ASSERTIONS)
endif ()
target_compile_options(ururu PRIVATE ${OPTS})

В чём разница? Хардкод флагов везде можно

Вообще об этом не задумываюсь, всё делает CMake.

всё на месте

$ ls /usr/local/lib/libmy*
/usr/local/lib/libmy.a  /usr/local/lib/libmy.la  /usr/local/lib/libmy.so  /usr/local/lib/libmy.so.0  /usr/local/lib/libmy.so.0.0.0

В чём разница? Хардкод флагов везде можно

Ну и какой смысл передавать такие флаги MSVC? Надо кучу if’ов … . А autotools это однообразная среда, простый шелл синтаксис. Если очень хочется винду, то мингв.

Кстати, о cmake: это я не разобрался, или в ней нет адекватного способа посмотреть (удобно, подобно configure –help) опции проекта? Как-то ковырял кеш, юзал какие-то костыли через awk для тривиальнейшей задачи.

autotools это однообразная среда

… в которой не

Надо кучу if’ов

Под виндой же всё равно не работает, что с if, что без )

это я не разобрался

Ага. cmake -LH

Вообще об этом не задумываюсь, всё делает CMake.

+++

)) О, спасибо. Надо запомнить, а то каждая встреча с cmake проектам превращалась в увлекательный квест. Хз, может недавно вкрутили, но awk’ный костыль находил где-то стековерфлоу.

Въехал. disable-shared немного о другом (управляет тем, что либтул создаёт на выходе). Тут же другой случай, если хочу линковать со статик, то либо писать полный путь к .a архиву, либо так

ain_LDADD = -lmy
main_LDFLAGS = -all-static

а если не передал флаг -all-static, то либтул будет линковать с либой (статик/со) на своё усмотрение в зависимости от возможностей системы. В общем-то обычное поведение, которое сохраняется и при сносе .la.

Зачем тогда la? Кто-нибудь знает? Есть предположение - такой способ сохранить зависимости для статических архивов (вроде pkg-config -static), которые зашиты в ELF, но отсутствуют в .a.

И ещё вопрос - существуют ли на сегодняшний системы (на которых можно autotools) в значимом количестве, которые не умеют разделяемый библиотеки? Т.е. может вообще не заморачиваться и клепать либы через -shared -fPIC?

https://www.gnu.org/software/libtool/manual/html_node/Using-Automake.html

тут в LDADD не ключ -l указывают, а просто файл .la, а libtool сам решает поддерживает ли платформа .so или .a

Зачем тогда la? Кто-нибудь знает? Есть предположение - такой способ сохранить зависимости для статических архивов (вроде pkg-config -static), которые зашиты в ELF, но отсутствуют в .a.

Оказывается, что можно встретиться со случаем, когда в динамических модулях собранных для dlopen() отсутствует информация о зависимостях (если не врут, то macos). Тут также используется .la через libtool libltdl. Может не такой уж и бесполезный костыль этот libtool, ну как писать какую-нибудь модульную софтину со сторонними программистами, которые будут давать свои модули? Линковать испольняемый файл со всем миром на всякий случай? Ну или писать свои костыли, которые превратятся в ещё один Libltdl с lib_мой_костыль.la.

disable-shared делает автотулзы собирать только статические библиотеки (т.е. те, которые собираются из исходников данного проекта), на линковку со сторонними библиотеками оно не влияет, нужно флагами линкера задавать

кыш

О линковке с la. После чтения доков/экспериментов пришёл к следующему: когда линковаться с la в _LDADD?

1. Хотим линковаться с либой статической + со всеми зависимостями, который сохраняются в la. Т.е. всякие pkg-config не устраивают (флаги -static, -all-static).
2. Слинкованная разделяемая либа часть проекта, который также содержит исполняемый файл линкуемый с этой либой. Тогда libtool создаст обёртку вместо бинаря, которая позволит запускать его (для теста) без установки либы в …/lib (через LD_PRELOAD, наверное).

Во всех иных случаях можно спокойно линковаться -lmy.

ЗЫ: всем спасибо, вроде libtool осилил.

автотулзятина

2020

mein Gott

Хотим линковаться с либой статической + со всеми зависимостями, который сохраняются в la. Т.е. всякие pkg-config не устраивают (флаги -static, -all-static).

Кстати, для .so’шек это тоже работает. Если либа lib1 слинкована с либой lib2, то линковка в стиле

gcc main.c lib1.so

не сделает main зависимым от lib2 (ld.so автоматом не загузит). Линковка с .la - сделает. Заргузка же модуля lib1 через dlopen подгрузит lib2 (не везде, для этого костылили lt_dlopen)

Лучше расскажи - как божественный cmake решает проблему зависимостей загружаемых модулей через dlopen на системах, где загрузчик их подгружать не будет?

Вопрос: почему когда libtool получает команду

libtool: link: g++ -O2 -DNDEBUG -o main main.o  -lmy

он не пытается слинковаться с libmy.la? Нужно передавать абсолютный путь /usr/local/lib/libmy.la. Может не понял идеи, но в чём смысл? Сделал я тесты через AC_CHECK_LIB, в LIBS набролось куча -lname, но libtool даже не пытается слинковать со своими же либами. А указывать абсолютный путь, ну как-то ненадёжно. Зачем так, может есть какой флаг, который изменит поведение (линковать с libmy.la при встрече -lmy)?

Щас набегут свидетели cygwin-а и msys

Я как свидетель и cygwin, и msys2, скажу что лучше не надо это использовать. Каждый раз, когда в Conan под винду нужно упаковать что-то собираемое при помощи autotools плотность мата на единицу объема рядом с моим компом опасно повышается.

ТС, действительно, используй CMake. Он и кроссплатформенный, и мейнстрим (что означает, что большую часть подводных камней до тебя нашли).

Под виндой не работает. Щас набегут свидетели cygwin-а и msys, но это работа в cygwin и msys, а не в винде. Ну и дока у cmake лучше

Лучше всего собирать кросс-компилятором из под линукса, на порядки быстрее, чем в винде под cygwin-ом

CMake - говно и ненужно

Написал по этому вопросу в libtool mailing list. Последний вопрос-ответ там не сохранился (может как-то криво отправли), вот они:

Thank you for reply.

Since you mention /usr/local/lib, can you confirm that LDFLAGS includes -L/usr/local/lib or that this argument was otherwise supplied to libtool?

No, I did not use the -L flag. When passing to libtool -L /usr/local/lib, the executable is linked to libmy.la (it is ok).

I think that libtool attempts to deduce the compiler’s default linking path so that it does not duplicate the default. However, the compiler’s default linking path might not match what is used by the operating system.

By «know in advance», do you mean that as a software developer you can’t know the configuration of some other system while building, …

Yes, I use atotools+libtool. As a developer, how can I discover library paths of end user which will build my package? For example, he has installed libraries in $HOME/lib, has set appropriate LIBRARY_PATH and has edited /etc/ld.so.conf so that they point to $HOME/lib. But libtool will not know about this and will not find those libraries. I thought libtool should somehow synchronize path information with linkers.

What is the right way when linking? Assigning most probable paths (/lib, /usr/lib, /usr/local/lib) with -L? $ libtool–mode=link g++ -L/lib -L/usr/lib -L/usr/local/lib … And if end user violates standard layout then this is his problem.

This is indeed a problem and likely not one with a perfect solution. Libtool is just a script. It asks GCC what paths it will use while linking. Sometimes GCC does not tell the truth.

Linux (I am assuming you are using Linux since you did not say) may use a different path based on the ldconfig configuration, which may be changed by the system administrator.

An important consideration is that a library may be installed multiple times. For example, I may install an updated/fixed version of a library in /usr/local/lib and I want my updated/fixed version to be used rather than the version installed by the OS’s package manager. In this case I would prefer that the directory path be in the opposite order you suggested. In this case, I might also want to use ldconfig to change the library search order, or perhaps I might hard-code the library run-path so that this is not necessary.

The golden rule should be that if the user specifies LDFLAGS to the configure script, that the linker search path specified there should always be given priority over defaults. This allows the user to take remedial action if the built-in assumptions are not correct.

If the user is doing something out of the ordinary (developers often do that!), then s/he should be able to influence the build process so search the correct directories for libraries and install to the correct location. The standard environment variables and arguments for influencing the build are provided by the standard INSTALL file.

Bob
Bob Friesenhahn

=======================================================

Хз, для меня так и осталось тайной - почему libtool не синхронизирует пути поиска lib с ld …

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

Использованаие libtool’ом тех же путей что и линкером:

#configure.ac
[ld_paths=$(${LD} --verbose | grep SEARCH_DIR | sed 's/); *SEARCH_DIR(/ -L/g; s/SEARCH_DIR(/ -L/; s/);//')]
AC_SUBST(ld_paths)

Makefile.am
main_LDFLAGS = $(ld_paths) 

Правда там что-то ещё компилятор добавляет, но несущественно, у меня выхлоп такой:

-L"/usr/x86_64-pc-linux-gnu/lib64" -L"/usr/lib" -L"/usr/local/lib" -L"/usr/x86_64-pc-linux-gnu/lib"

Тут много auto хейтеров, как я погляжу. Ребят libtool это необязательно, можно не писать макрос LT_INIT и его вообще не будет. Просто инструмент такой есть, нужно как-то его понимать.

Просто инструмент такой есть, нужно как-то его понимать.

А другие инструменты ты уже понимаешь? Meson там или Cmake? Осталось только autotools для коллекции? Если нет, то почему сперва выбрал изучить autotools?

Потому что это классическое, проверенное временем универсальное кроссплатформенное решение. В отличие от новомодной хипстоты

Когда-то пробовал Cmake, но чего-то не проникся.

почему сперва выбрал изучить autotools?

)) А почему нет? Он прост, логичен, без лишних абстраций (не считая libtool), почему он должен меня не устраивать? И никто не запрещает кросскомпиляцию под винду на Линуксе. Cmake прост для типового hellow world, а что если мы хотим отключить strict aliasing оптимизацию, например? Божественный Cmake должен накинуть ещё один слой абстракции реализующий опции под каждый компилятор ). Вот вообще не охота связывать себе как-то руки из-за этой недоОС. Пусть винда становится Unix like, и тогда сможет спокойно собирать софт, а пока пусть страдают.

В configure.ac LT_INIT тебе не нужен. Достаточно прописать в Makefile.am main_LDADD = libmy.a