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

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

waker ★★★★★
() автор топика
Ответ на: комментарий от Anon
~/SDE-src/libsde-utils$ cmake -Dprefix=$HOME/SDE
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    prefix

README нет, INSTALL нет. Okay, читаем документацию:

~/SDE-src/libsde-utils$ cmake -DCMAKE_INSTALL_PREFIX=$HOME/SDE
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tc/SDE-src/libsde-utils
~/SDE-src/libsde-utils$ make
Scanning dependencies of target sde-utils-1.0
[ 20%] Building C object src/CMakeFiles/sde-utils-1.0.dir/strings.c.o
[ 40%] Building C object src/CMakeFiles/sde-utils-1.0.dir/paths.c.o
[ 60%] Building C object src/CMakeFiles/sde-utils-1.0.dir/proc.c.o
[ 80%] Building C object src/CMakeFiles/sde-utils-1.0.dir/launcher.c.o
[100%] Building C object src/CMakeFiles/sde-utils-1.0.dir/log.c.o
Linking C shared library libsde-utils-1.0.so
CMakeFiles/sde-utils-1.0.dir/proc.c.o: In function `su_get_module_path':
proc.c:(.text+0x1b): undefined reference to `dladdr'
collect2: выполнение ld завершилось с кодом возврата 1
make[2]: *** [src/libsde-utils-1.0.so] Ошибка 1
make[1]: *** [src/CMakeFiles/sde-utils-1.0.dir/all] Ошибка 2
make: *** [all] Ошибка 2

читаем документацию еще:

~/SDE-src/libsde-utils$ make VERBOSE=1
...
/usr/bin/gcc  -fPIC  -Wall -Wextra -ldl -Wl,--no-undefined   -shared -Wl,-soname,libsde-utils-1.0.so -o libsde-utils-1.0.so CMakeFiles/sde-utils-1.0.dir/strings.c.o CMakeFiles/sde-utils-1.0.dir/paths.c.o CMakeFiles/sde-utils-1.0.dir/proc.c.o CMakeFiles/sde-utils-1.0.dir/launcher.c.o CMakeFiles/sde-utils-1.0.dir/log.c.o -lglib-2.0 
CMakeFiles/sde-utils-1.0.dir/proc.c.o: In function `su_get_module_path':
proc.c:(.text+0x1b): undefined reference to `dladdr'
collect2: выполнение ld завершилось с кодом возврата 1

-ldl не там. В autotools такой херни не было.

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

Проморгал пейсатель.

Чсх, -lglib-2.0 там, где надо.

А что за прикол в хомяк устанавливать? Что за изврат?

Изврат это делать из системы слакварь, устанавливая в /usr. А устанавливать в $HOME/dir это рабочий и несущественный момент.

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

А что за jansson такой? У тебя в дереве его нет

это не мое дерево.

sde/libsde-utils-jansson.git

А что за прикол в хомяк устанавливать? Что за изврат?

а что за прикол шлангом быть? вон, нормальный человек выше без проблем справился, и проблем у него не вызвало. у тебя проблемы с умственным развитием?

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

вот так собралось:

diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index c0bb233..10d8850 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -3,12 +3,14 @@ if(ENABLE_WERROR)
     set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Werror")
 endif()
 
-set(CMAKE_SHARED_LINKER_FLAGS "-ldl -Wl,--no-undefined ${CMAKE_SHARED_LINKER_FLAGS}")
+set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_SHARED_LINKER_FLAGS}")
 
 ##############################################################################
 
 find_package(PkgConfig REQUIRED)
-pkg_check_modules(glib2 REQUIRED glib-2.0>=2.36)
+pkg_check_modules(glib2 REQUIRED glib-2.0>=2.32)
+
+find_library(LIBDL_LIBRARY dl)
 
 add_definitions(
     ${glib2_CFLAGS}
@@ -25,6 +27,7 @@ add_library(sde-utils-1.0 SHARED
 
 target_link_libraries(sde-utils-1.0
     ${glib2_LIBRARIES}
+    ${LIBDL_LIBRARY}
 )
 
 file(GLOB headers "${CMAKE_CURRENT_SOURCE_DIR}/*.h")

Версию glib раньше исправил. Может быть знатоки cmake скажут как сделать dl не опциональной.

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

Туплю уже. Не получилось у меня сделать make install: ругается на sde-utils-1.0.pc.

ну так надо сначала было sde-utils собрать и поставить

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

ну по крайней мере, это был баг в CMakeList.txt, а не в cmake. и то хорошо. принципиально, так можно и в автотулсах напортачить. другой вопрос что в автотулсах ошибка сразу на виду, и не надо искать вот это VERBOSE=1 в документациях.

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

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

shit! Это я тупил уже (спать охота): забыл подчистить cmake'овский кеш.

Итак:

mkdir tmp && cd tmp && cmake .. -DCMAKE_INSTALL_PREFIX=$HOME/SDE && make && make install

git diff
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 597a780..05fa81d 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -7,7 +7,3 @@ option(ENABLE_WERROR "Enable -Werror flag for development" OFF)
 include(GNUInstallDirs)
 
 add_subdirectory(src)
-
-configure_file(sde-utils-1.0.pc.in sde-utils-1.0.pc @ONLY)
-
-install(FILES sde-utils-1.0.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
\ No newline at end of file
diff --git a/sde-utils-1.0.pc.in b/sde-utils-1.0.pc.in
deleted file mode 100644
index fc659cd..0000000
--- a/sde-utils-1.0.pc.in
+++ /dev/null
@@ -1,10 +0,0 @@
-prefix=@CMAKE_INSTALL_PREFIX@
-libdir=${prefix}/@CMAKE_INSTALL_LIBDIR@
-includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@
-
-Name: sde-utils
-Description: SDE C Utility Library
-Version: 0.1
-Requires: glib-2.0 gobject-2.0
-Libs: -L${libdir} -lsde-utils-1.0
-Cflags: -I${includedir}/sde-utils-1.0
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index c0bb233..0d1de81 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -8,7 +8,8 @@ set(CMAKE_SHARED_LINKER_FLAGS "-ldl -Wl,--no-undefined ${CMAKE_SHARED_LINKER_FLA
 ##############################################################################
 
 find_package(PkgConfig REQUIRED)
-pkg_check_modules(glib2 REQUIRED glib-2.0>=2.36)
+pkg_check_modules(glib2 REQUIRED glib-2.0)
+find_library(LIBDL_LIBRARY dl REQUIRED)
 
 add_definitions(
     ${glib2_CFLAGS}
@@ -27,8 +28,10 @@ target_link_libraries(sde-utils-1.0
     ${glib2_LIBRARIES}
 )
 
+configure_file(sde-utils-1.0.pc.in sde-utils-1.0.pc @ONLY)
+
 file(GLOB headers "${CMAKE_CURRENT_SOURCE_DIR}/*.h")
 install(FILES ${headers} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/sde-utils-1.0/sde-utils)
 install(FILES sde-utils.h DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/sde-utils-1.0)
 install(TARGETS sde-utils-1.0 LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}/)
-
+install(FILES sde-utils-1.0.pc DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)
Anon
()
Ответ на: комментарий от Anon

ну а где же хваленая крутость cmake, если им ничего собрать не получается, не пропатчив для начала все CMakeList.txt?

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

не пропатчив для начала все CMakeList.txt?

Чувак, хочешь я тебе сейчас полной херни в configure.ac напишу и тоже матюкаться буду?

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

Чувак, хочешь я тебе сейчас полной херни в configure.ac напишу и тоже матюкаться буду?

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

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

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

ЗЫ причем тот же cmake имеет спец переменные для легкого внедрения зависимостей (например в виде git submodule) и эти скрипты строяться в правильное дерево, что позволяет без гемора разрабатывать зависимые проекты.

punya ★★
()
Последнее исправление: punya (всего исправлений: 2)
Ответ на: комментарий от AptGet

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

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

не нашел форка где бы выпиливалась эта нечисть

Так и запишем - на cmake задача не рещается.

cmake и др имеют модульную структуру. в каждой папке лежал бы

В каждой папке лежала бы своя мамка, да.

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

Лень точно считать строки, но там в корне 1000+ строк в разных cmake-файлах; configure.ac в Wine 3.5k строк. Не вижу качественного превосходства.

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

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

punya ★★
()
Последнее исправление: punya (всего исправлений: 1)
Ответ на: комментарий от punya

посмотри комиты как делаются в вайн. каждый патч практически что-то правит в этом огромном конфиге.

Специально склонировал и посмотрел - этот файл затрагивают 1.5% от общего числа коммитов.

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

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

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

меинтейнеру гемор с ним возится, проверяя сделано изменение там где надо, не поломает ли оно остальное.

Ну да, после патча на систему сборки нужно проверять, не сломалась ли сборка. И что?

Я не против cmake (хотя его язык эталонно уродлив), просто не вижу киллер-фич по сравнению с autotools.

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

не вижу киллер-фич по сравнению с autotools

Скорость генерации Makefile'ов + синтаксис более человечный.

Но, конечно, в идеале система автосборки должна тупо сканировать все файлы проекта, генерировать нужные флаги для gcc, делать make. Только это в общем случае уже пованивает телепатией.

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

У меня сейчас стоит три разных версии automake + automake-wrapper который их как-то разруливает.
А вот cmake хватает одной версии.
Считаю, явный профит.

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

-Wl,--no-undefined

И это не соберётся на Солярисе.

dl

А как насчёт libdld ;-)

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

Ты не понял фишку.

automake и проч. нужны только разработчику.

cmake нужен и пользователю. И ты не можешь контролировать, какая версия стоит у пользователя.

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

ты не можешь контролировать, какая версия стоит у пользователя

Я видел несколько проектов, где все нужные симейковские "файнды" позапихивали в проект же. В итоге: какая бы у тебя версия не стояла, оно (по идее) будет работать.

А вообще, ты тоже неправ: обычному хомячку нужно тыкать мышкой в инсталляционный пакет. А не-хомячок имеет свежий cmake у себя на системе ☺

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

посмотри комиты как делаются в вайн. каждый патч практически что-то правит в этом огромном конфиге.

в конфигах cmake ты не найдешь адских скриптов для поиска/тестирования библиотек, заголовочных файлов, свойств железа, оси и тд.

Поэтому проекты не собираются на машине отличной от той, что у горе-разработчика

все вынесено и используется огромным числом проектов. да и cmake конфиги наполнены в основном списком файлов для сборки

Выучи уже матчасть, например, про config.guess

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

automake и проч. нужны только разработчику.

Угу, что же это гента их за собой тягает?

cmake нужен и пользователю. И ты не можешь контролировать, какая версия стоит у пользователя.

Ага, порой так весело бывает, когда разработчик сгенерил кривой configure.sh.

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

Я видел несколько проектов, где все нужные симейковские «файнды» позапихивали в проект же.

Руками? В autotools это автоматически и by design.

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

Погуглил. Это трындец. Вот еще из-за чего автотулзы — такое тормознутое дерьмо.

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

Угу, что же это гента их за собой тягает?

Ну толсто же!

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

Да не надо меня пытаться переубедить. Эти ваши автотулзы — тормозное угребище.

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

порой так весело бывает, когда разработчик сгенерил кривой configure.sh

Примерно половина пакетов, которые я пытаюсь установить в обход пакетного менеджера (например, "на полюбопытствовать"), сталкиваюсь с подобным. Пожалуй, процентов 10 — те, которые я вообще не смог скомпилять (слишком длинный и уродливый был конфигуратор).

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

Поэтому проекты не собираются на машине отличной от той, что у горе-разработчика

cmake проекты не собираются на других машинах? чаво?

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

а каким боком к этому завоевание девелоперских сердец cmake'ом?

Это было к разговору о «стандарте де-факто». Что чтобы навязать всем единый стандарт (будь то autocrap, cmake или что-то еще), должен быть собор. А у нас базар: люди используют разные ОС, разные ЯП, разные системы сборки. Одновременно живёт куча конкурирующих друг с другом и заимствующих друг у друга решений.

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