LINUX.ORG.RU

как избавиться от libtool не избавляясь от automake?

 , ,


5

5

всем привет.

в первую очередь, попрошу фанатов cmake покинуть помещение, за исключением тех кто разбирается в предмете, и может сообщить что-то по теме. промахнувшихся темой буду нещадно френдить.

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

есть automake, есть много Makefile.am, в которых делается что-то вроде такого:

pkglib_LTLIBRARIES = mylibrary.la
mylibrary_la_SOURCES = mylibrary.c
mylibrary_la_LDFLAGS = -module

соответственно, для таких модулей будет использоваться libtool, который

  • сгенерирует огромную кучу всяких файлов, типа .la, .lo, .lai, .Plo
  • при сборке будет автоматически использоваться libtool при подключении чужих библиотек, используя .la файлы в /usr/lib например
  • помимо mylibrary.so, будут сгенерированы mylibrary.so.0.0.0 и mylibrary.so.0, и засимлинканы друг на друга
  • при попытке кросскомпилить, или использовать не-системные версии библиотек при сборке, libtool ведет себя совершенно непредсказуемо, выдает бредовые ошибки, использует не те библиотеки которые ему сказано, и вообще говно.
  • .la файлы будут включены в install target, и создадут бесполезный мусор в /usr/lib
  • сборка статического билда очень усложняется, т.к. неизвестно, увидел ли libtool именно нужную библиотеку, или слинковался с системной (а это он умеет)
  • к библиотекам неявно прилинковывается всякий шлак, который добавляется по типу исходника — например, при сборке .cpp файлов автоматом к линку добавляется всякий libstdc++ и libgcc_s, даже если он не нужен, т.е. в скрипте libtool (некоторых версиях) можно увидеть добавление вот таких аргументов к командной строке "-lstdc++ -lm -lgcc_s -lc -lgcc_s", gcc_s 2 раза видимо для надежности.

короче, предполагается, что целевая аудитория данного треда в курсе о чем речь :)

ну и собсно, финальный вопрос. есть ли в природе какие-то альтернативные automake macros, чтобы вообще совсем навсегда избавиться от libtool?

что от макроса(-ов) требуется:

  • компилить .so, как с префиксом «lib», так и без него, т.е. как в libtool с -module
  • чтобы указание -lname линковало только libname.so из -L (с соблюдением стандартного search order), и всегда игнорировало .la файлы в $LIBDIR
  • чтобы никаких la файлов и versioned so не создавалось (опциональная возможность versioning приветствуется)
  • чтобы сборка работала на linux/win/osx/bsd (через gcc/llvmgcc)

понимаю, что вменяемого способа решить эту проблему может и не быть, поэтому предложения полной смены билд системы тоже приветствуются. но альтернативная система не должна требовать установки ничего кроме make+coreutils у юзера, и должна быть не хуже autotools по фичам — т.е. уметь make distcheck, make install/uninstall, использовать configure, и всякие подобные штуки (в связи с чем предлагателей cmake, опять же, попрошу не обращаться).

например, кто-то смотрел что используется в ffmpeg? там что-то свое, или у него есть сайт?

★★★★★

Ответ на: комментарий от Anon

Можно подумать, с фортраном однозначно!

можно подумать, что я где-то это утверждал. я фортран никогда в глаза не видел.

waker ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Я выше такое сравнение приводил: cmake — 5 секунд, автотулзы — 15. Каково, а?

Anon
()
Ответ на: комментарий от anonymous

Ты говорил о разнице в скорости.

Я говорил о том, что затраты времени на конфигурение иногда бывают весьма существенными.

Manhunt ★★★★★
()
Ответ на: комментарий от waker

у меня от cmake такие впечатления.

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

У меня сейчас половина проектов собирается cmake-ом, потому как я чего-то репу почесал и решил, что нагревать атмосферу, гоняя ./configure при сборке кучи мелочи, компиляция которой занимает на порядки меньше времени, чем эта самая ./configure, — херовая идея.

// geekless

anonymous
()
Ответ на: комментарий от waker

аналоги AC_CHECK_LIB и PKG_CHECK_MODULES есть?

Вот такая простыня:

find_package(PkgConfig REQUIRED)
pkg_check_modules(gtk2 REQUIRED gtk+-2.0>=2.24)
pkg_check_modules(glib2 REQUIRED glib-2.0>=2.36)
pkg_check_modules(jansson REQUIRED jansson>=2.4)
pkg_check_modules(sde_utils REQUIRED sde-utils-1.0>=0.1)
pkg_check_modules(sde_utils_gtk REQUIRED sde-utils-gtk-1.0>=0.1)

##############################################################################

add_definitions(
    ${gtk2_CFLAGS}
    ${glib2_CFLAGS}
    ${jansson_CFLAGS}
    ${sde_utils_CFLAGS}
    ${sde_utils_gtk_CFLAGS}
)

link_directories(
    ${gtk2_LIBRARY_DIRS}
    ${glib2_LIBRARY_DIRS}
    ${jansson_LIBRARY_DIRS}
    ${sde_utils_LIBRARY_DIRS}
    ${sde_utils_gtk_LIBRARY_DIRS}
)

target_link_libraries(sde-utils-jansson-1.0
    ${glib2_LIBRARIES}
    ${jansson_LIBRARIES}
    ${gtk2_LIBRARIES}
    ${sde_utils_LIBRARIES}
    ${sde_utils_gtk_LIBRARIES}
)

Это я еще забыл тут директиву include_directories дописать, кстати. Баг.

В общем, «всё вручную, атайды, щас брызнет». Какого-либо высокоуровневой абстракции над вызовом pkg_check_modules() и последующим засовыванием результатов его работы во все нужные места, документация по тулзе не содержит. И вообще документация мутная, хрен чо найдёшь без грепа.

На полном серьёзе предлагают для каждой библиотеки писать кастомные «файндеры» и ставить оные файндеры как cmake-модули при установке библиотеки в систему. Про то, что pkg_check де-факто стандарт, и за кастомные файндеры в приличных обществах принято бить ногами, там никто не слышал. Поколение Windows, блеать.

Можно конечно написать более высокоуровневую абстракцию над pkg_check_modules вручную. (Наверное.) Но поскольку её никто не написал и в стандартный набор макросов не добавил, похоже, всех всё устраивает вот так.

соберется ли проект, если в cmakelist указана зависимость от liba.so, а она не установлена (но при этом для сборки опциональна)?

Так же как и в автоллузах: чекаешь наличие зависимости, а потом ветвишься. Вот там выше в моём примере REQUIRED указано, значит сборка вылетит на этом этапе при отсутствии. Можно не указывать.

// geekless

anonymous
()
Ответ на: комментарий от waker

пошлю линк на твой патч geekless'у, думаю он будет рад. спасибо, что разобрался.

Надо будет сегодня всё-таки обраться до своей почты. :D Thanks.

// geekless

anonymous
()
Ответ на: комментарий от anonymous

У меня сейчас половина проектов собирается cmake-ом, потому как я чего-то репу почесал и решил, что нагревать атмосферу, гоняя ./configure при сборке кучи мелочи, компиляция которой занимает на порядки меньше времени, чем эта самая ./configure, — херовая идея.

открой для себя --enable-maintainer-mode :)

waker ★★★★★
() автор топика
Ответ на: комментарий от anonymous

просто звиздец какой-то.

waker ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Но поскольку её никто не написал и в стандартный набор макросов не добавил, похоже, всех всё устраивает вот так.

Чего это? FindPkgConfig.cmake - стандартный модуль!

AF ★★★
()
Ответ на: комментарий от waker

При чем тут это? MAINTAINER_MODE отвечает за (не)перегенерацию сборочной среды при изменении её сорцовых файлов. Я вообще не про то.

У меня есть куча мелких библиотек (и будет еще больше), для которых время работы ./configure в несколько раз превышает время работы непосредственно компилятора и линковщика. Нафиг мне такое счастье.

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

Ну а в целом всё это затеяно, чтобы изучить новый инструмент. Тем более, что сборка под другие платформы мне не грозит. Пока что инструмент так себе, шило на мыло.

anonymous
()
Ответ на: комментарий от AF

Чего это? FindPkgConfig.cmake - стандартный модуль!

Сначала надо сделать pkg_check_modules, а потом вручную засунуть все переменные во всех места, где это нужно. См. мой пример выше.

В автотулзах то же самое, но гораздо лаконичнее делается. Например:

# Checks for libraries.
pkg_modules="gtk+-2.0 >= 2.24.0 \
             gio-unix-2.0 \
             gthread-2.0 \
             gmodule-2.0 \
             jansson >= 2.4 \
             sde-utils-1.0 >= 0.1 \
             sde-utils-x11-1.0 >= 0.1 \
             sde-utils-jansson-1.0 >= 0.1 \
             sde-utils-gtk-1.0 >= 0.1"
PKG_CHECK_MODULES(PACKAGE, [$pkg_modules])
AC_SUBST(PACKAGE_CFLAGS)
AC_SUBST(PACKAGE_LIBS)

pkg_modules="x11 xcomposite"
PKG_CHECK_MODULES(X11, [$pkg_modules])
AC_SUBST(X11_CFLAGS)
AC_SUBST(X11_LIBS)

Или я не умею компактно писать на этих ваших cmake-ах? Покажи тогда, как. Все примеры, какие я видел, пишут такие же длинные простынки, как я выше цитировал.

anonymous
()
Ответ на: комментарий от anonymous

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

ну если тебе надо собирать пакеты несколько раз в день - то да, наверное проблема есть.. я пакеты раз в год собираю.

waker ★★★★★
() автор топика
Ответ на: комментарий от waker

ты бы это.. на кошках сначала потренировался, чтоли :)))

на кошках

This! :D

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.