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? там что-то свое, или у него есть сайт?

★★★★★

(в связи с чем предлагателей cmake, опять же, попрошу не обращаться)

scons тогда =)

UVV ★★★★★
()

чтобы никаких la файлов и versioned so не создавалось (опциональная возможность versioning приветствуется)

Чё будешь делать, если API поменяется?

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

scons тогда =)

он ничем не лучше cmake

Чё будешь делать, если API поменяется?

тема не про это.

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

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

UVV ★★★★★
()
Последнее исправление: UVV (всего исправлений: 1)

альтернативная система не должна требовать установки ничего кроме make+coreutils у юзера

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

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

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

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

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

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

меня все устраивает в craptools, кроме libtool. вот ищу ему замену :)

waker ★★★★★
() автор топика

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

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

AF ★★★
()

ЧЯДНТ?

я не ту комманду для получения списка зависмостей ввожу? или требуется make+coreutils и баста?

santa@sai:~$ apt-cache depends cmake
cmake
  Depends: libarchive12
  Depends: libc6
  Depends: libcurl3-gnutls
  Depends: libexpat1
  Depends: libgcc1
  Depends: libstdc++6
  Depends: libxmlrpc-core-c3
  Depends: zlib1g
  Depends: cmake-data
  Depends: procps
    procps:i386
  Suggests: gcc
  Suggests: make
  Conflicts: cmake:i386

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

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

покажи релевантный кусок Makefile.am и выхлоп make.

статическую либу как линкуешь? через -l? попробуй подсунуть напрямую libname.a с полным путем.

waker ★★★★★
() автор топика

Вообще, для кросс-компиляции libtool можно готовить, да так, что получается значительно удобнее всех прочих альтернатив. Посмотри как его готовят товарищи из OpenEmbedded. С другой стороны соглашусь, что нормально кросс-компиляцию и сохранение адекватности ни одна из современных автособиралок не умеет.

slapin ★★★★★
()
Ответ на: ЧЯДНТ? от x0r

я не ту комманду для получения списка зависмостей ввожу? или требуется make+coreutils и баста?

требуется, чтобы не надо было устанавливать cmake.

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

Вообще, для кросс-компиляции libtool можно готовить, да так, что получается значительно удобнее всех прочих альтернатив. Посмотри как его готовят товарищи из OpenEmbedded. С другой стороны соглашусь, что нормально кросс-компиляцию и сохранение адекватности ни одна из современных автособиралок не умеет.

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

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

статическую либу как линкуешь? через -l? попробуй подсунуть напрямую libname.a с полным путем.

Ну я вообщето кроскомпилю с помощью http://mxe.cc Только там все в статике собирается, а я большую часть в шареных библиотеках хочу иметь. Что там внутри ХЗ, не заглядывал. Пока все собрал в шареных библиотеках, но осадочек остался.

Логов пока не будет, они дето дома.

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

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

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

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

Ты же в курсе, что в динамических библиотеках PIC-код, а в статических - нет?

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

Ты же в курсе, что в динамических библиотеках PIC-код, а в статических - нет?

разве кто-то запрещает пересобрать статические с CFLAGS=-fPIC?

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

Ага, вкурсе, насколько я помню, у меня в кросскомпилере он по дефолту включен, так что все ок.

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

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

и выпить яду.

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

libtool вообще всячески мешает использовать static libs сам по себе.

Со статикой проблем не замечал. Траблы, только когда смешиваю статик и шаред

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

Со стакий пороблем не замечал. Траблы, только когда смешиваю статик и шаред

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

waker ★★★★★
() автор топика

сгенерирует огромную кучу всяких файлов, типа .la, .lo, .lai, .Plo

И чо? make clean

при сборке будет автоматически использоваться libtool при подключении чужих библиотек, используя .la файлы в /usr/lib например

В нормальных дистрибутивах их принято удалять

помимо mylibrary.so, будут сгенерированы mylibrary.so.0.0.0 и mylibrary.so.0, и засимлинканы друг на друга

-avoid-version, http://stackoverflow.com/questions/11989255/gnu-autotools-rebuild-without-ver...

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

./configure LDFLAGS="-L/foo"

.la файлы будут включены в install target, и создадут бесполезный мусор в /usr/lib

Он бесполезен только на multiarch-системах, типа Дебиана

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

./configure --enable-static --disable-shared

к библиотекам неявно прилинковывается всякий шлак, который добавляется по типу исходника — например, при сборке .cpp файлов автоматом к линку добавляется всякий libstdc++ и libgcc_s,

Это делает gcc/g++, а не libtool

даже если он не нужен, т.е. в скрипте libtool (некоторых версиях) можно увидеть добавление вот таких аргументов к командной строке "-lstdc++ -lm -lgcc_s -lc -lgcc_s", gcc_s 2 раза видимо для надежности.

LDFLAGS="-Wl,--as-needed"

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

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

./configure --enable-static --disable-shared

Вру. Тут дело не в libtool, а в ld: -Bstatic/-Bdynamic

Учи матчасть уже, не будь истеричкой!

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

разве кто-то запрещает пересобрать статические с CFLAGS=-fPIC?

Так и не смог придумать применения таким мутантам. Ваш вариант «вкомпилить *.a в *.so» - зачем он? Какая разница, с одной сошкой линкуешься или с несколькими?

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

Большое число маленких so-шек тормозит загрузку.

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

В нормальных дистрибутивах их принято удалять

абсолютно верно. хочется чтобы они не создавались. и что еще более важно — не использовались, даже если присутствуют.

-avoid-version

спасибо за инфу, попробую вечером

./configure LDFLAGS="-L/foo"

угу, так и делаю, ессно

Он бесполезен только на multiarch-системах, типа Дебиана

в моем проекте он бесполезен на абсолютно всех системах.

./configure --enable-static --disable-shared

речь не о сборке отдельной библиотеки статиком, а о сборке проекта использующего десятки разных библиотек. в самом проекте есть динамические библиотеки, но они слинкованы со своими зависимостями статиком. это совсем не то, что делает --enable-static --disable-shared.

Это делает gcc/g++, а не libtool

это делает libtool. я принудительно указываю -nostdlib, а libtool их добавляет. в данный момент, билдскрипт sed'ом удаляет это из libtool. очередной костыль. причем есть версии libtool которые этого не делают, например в убунте12.04, а в арче вот такая хрень.

LDFLAGS="-Wl,--as-needed"

не уверен, что это поможет. но обязательно проверю.

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

Учи матчасть уже, не будь истеричкой!

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

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

Так и не смог придумать применения таким мутантам. Ваш вариант «вкомпилить *.a в *.so» - зачем он? Какая разница, с одной сошкой линкуешься или с несколькими?

а зачем еще нужны *.a?

waker ★★★★★
() автор топика

компилить .so, как с префиксом «lib», так и без него, т.е. как в libtool с -module

Сделай две библиотеки из одних и тех же исходников.

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

Сделай две библиотеки из одних и тех же исходников.

не, ты не понял. мне не надо 2 одновременно. и libtool с этим справляется через -module. это требование к альтернативной системе, чтобы она тоже это умела.

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

читал. там написано как использовать libtool. а нужно как не использовать libtool.

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

С системами сборки как с криптографией - не изобретай своего, если это не твоя профессия.

и да, моя профессия напрямую связана в т.ч. с системами сборки.

waker ★★★★★
() автор топика

Вот чем тебя cmake не устраивает? Простая система сборки, да немного с uninstall надо велосипедить, и что? Я вообще не парюсь насчет uninstall...

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

Провожу ликбез:

1. Рулят autotools и cmake

2. autotools для открытых проектов (free software)

3. cmake для закрытых.

Это видно даже при сравнении «make dist» и CPack ;-)

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

Вот чем тебя cmake не устраивает? Простая система сборки, да немного с uninstall надо велосипедить, и что? Я вообще не парюсь насчет uninstall...

хм. я разве не написал выше чем? странно. а думал, что написал.

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

1. Рулят autotools и cmake

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

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

У всех связана, лол. Но творят только GNU и KitWare.

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

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

Такого количества феерических косяков, как в libtool, я не видел пожалуй больше нигде.

+1

waker ★★★★★
() автор топика

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

в ffmpeg, а также в qemu и nginx (и мб где-то ещё), используется самописный configure и самописные Makefile'ы. Рекомендую.

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

в ffmpeg, а также в qemu и nginx (и мб где-то ещё), используется самописный configure и самописные Makefile'ы. Рекомендую.

эх.. а я то надеялся. да, этот вариант тоже рассматриваю. если не найду как избавиться от libtool в automake, то видимо придется.

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

Если обезьяне дать лопату, обезьяна останется обезьяной.

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

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

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

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

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

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

Любой инструмент имеет область применимости. Область применимости libtool - ПРИЧИНЕНИЕ БОЛИ И СТРАДАНИЙ.

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

Обратись к доктору, лол. Он починит твои ручки.

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