[msys] некоторые аспекты сборки библиотек
Править нельзя, так что добавлю касательно пункта 2. Не все библиотеки пользуются libtool, в результате иногда либы собираются и .so суффиксом
Есть впечатление, что опенсорс-фонаты, радеющие за кроссплатформенность, не подразумевают под кроссплатформенностью возможность сборки (и нормальной работы) под виндой. 
Есть впечатление, что твое впечатление неверно.
да, ты не прав тут на самом деле. все от проекта зависит,
большАя часть новых приложений собирается более адекватными, чем libtool тулзами.
большАя часть новых приложений собирается более адекватными, чем libtool тулзами.
большАя часть новых приложений собирается более адекватными, чем libtool тулзами.Если ты про pkgsrc и знаешь что это такое, то расскажи, пожалуйста подробнее, как им пользоваться.
Есть впечатление, что опенсорс-фонаты, радеющие за кроссплатформенность, не подразумевают под кроссплатформенностью возможность сборки (и нормальной работы) под виндойформально они правы. Работают же нахаляву, им не с руки ещё MSный софт покупать, чтобы тестить совместимость.
это контра наверное расскажет подробно (и оно же не для сборки, кажется?).
я имею в виду scons/cmake.
scons-у не трудно работать под виндой, потому что он на питоне написан.
cmake тоже есть под винду, я даже знаю пару небольших проектов, которые с его помощью на ней успешно собираются.
и kde же щас на cmake и существует под винду. да?
я имею в виду scons/cmake.
scons-у не трудно работать под виндой, потому что он на питоне написан.
cmake тоже есть под винду, я даже знаю пару небольших проектов, которые с его помощью на ней успешно собираются.
и kde же щас на cmake и существует под винду. да?
это контра наверное расскажет подробно (и оно же не для сборки, кажется?).1. Она для сборки и удовлетворения зависимостей библиотек. Активно используется gnomовскими проектами.
я имею в виду scons/cmake.
scons-у не трудно работать под виндой, потому что он на питоне написан.
cmake тоже есть под винду, я даже знаю пару небольших проектов, которые с его помощью на ней успешно собираются.
и kde же щас на cmake и существует под винду. да?
2. Мне почему-то кажется, что gnumake+m4+autohell куда более гибкое.
3. cmake есть под винду. Некоторые небольшие проекты я тебе и майкрософтовской VS соберу.
4. Не знаю на чём kde, я mplayer собираю. Причём вместе с кучей зависимых либ (все что портированы беру).
Кстати, поправьте меня, если ошибаюсь. Мне кажется, что если я вместо честного хоста mingw буду компилить на хост win32, то я потеряю кучу фич. Это так?
2. Мне почему-то кажется, что gnumake+m4+autohell куда более гибкое.почему? ты же вон сколько проблем в первом постинге описал.
cmake на юниксах генерит мейкфайлы, сконс — это скрипт на питоне (куда уж гибче).
3. cmake есть под винду. Некоторые небольшие проекты я тебе и майкрософтовской VS соберу.ну вот kde таки cmake-ом.
bugaga ~ $ cat /usr/portage/eclass/kde4-base.eclass | grep "^inherit"
inherit base eutils multilib cmake-utils kde4-functions
4. Не знаю на чём kde, я mplayer собираю. Причём вместе с кучей зависимых либ (все что портированы беру).ну тут только посочувствовать можно. гибкости автохелла. =(
причем вряд ли это будет кто-то исправлять.
Есть впечатление, что опенсорс-фонаты, радеющие за кроссплатформенность, не подразумевают под кроссплатформенностью возможность сборки (и нормальной работы) под виндой.ну вайн под винду портирован, значит можно портировать под вайн и оно автомагически заработает и на винде =)
Мне почему-то кажется, что gnumake+m4+autohell куда более гибкое.ах если бы, ах если бы... все auto* скрипты во всём софте были написаны правильно то это имелобы какой-то смысл. а так благодаря этой гибкости каждый изобретает новый велосипед, который не всегда ездюет даже на автотулзах другой версии чем у автора =)
Быть может кто-нибудь уже сталкивался с ними, и сможет помочь советом.теме ап. Собственно, кроме оффтопа, никто ничего умного породить не может? Больше всего интересует вопрос 1 и 3. Про pkgsrc хотелось бы что-нить услышать от того, кто хоть раз им воспользовался.
mplayer auto* не использует давно, там у них самопал маскирующийся под него
не использует, я это прекрасно знаю. Но вот только туева хуча либ использует, а без них mplayer не интересен.
Оказывается бывают вещи пострашнее автохела. Только что встретился с отсутствием какой-либо дополнительной конфигурации, кроме make. make help меня поразил, кстати, своей интуитивной понятностью
А инсталла вообще не предусмотрено. Только десять вариантов очистки.
Run one of the following command lines:
make clean GC (to build the GNU C dll with C cleanup code)
make clean GCE (to build the GNU C dll with C++ exception handling)
make clean GC-inlined (to build the GNU C inlined dll with C cleanup code)
make clean GCE-inlined (to build the GNU C inlined dll with C++ exception handling)
make clean GC-static (to build the GNU C inlined static lib with C cleanup code)
make clean GC-debug (to build the GNU C debug dll with C cleanup code)
make clean GCE-debug (to build the GNU C debug dll with C++ exception handling)
make clean GC-inlined-debug (to build the GNU C inlined debug dll with C cleanup code)
make clean GCE-inlined-debug (to build the GNU C inlined debug dll with C++ exception handling)
make clean GC-static-debug (to build the GNU C inlined static debug lib with C cleanup code)
А инсталла вообще не предусмотрено. Только десять вариантов очистки.
При попытке собирать софт с помощью системы msys/mingw cтолкнулся с несколькими проблемами, связанными со статическими и динамическими библиотеками.Ты скачал и скомпилировал самые новые autoconf, automake и libtool или пользуешься теми, что ставятся с MSYS?
Ты скачал и скомпилировал самые новые autoconf, automake и libtool или пользуешься теми, что ставятся с MSYS?
2. Собственноручно собранный libtool последней версии страдает шизофренией (прекомпилированные варианты фатально не поспевают за мейнстримом, и большинство библиотек с их помощью невозможно собрать).
Это я прочитал, но там нету про автотулзы. Когда-то мне пришлось пересобрать autoconf, automake и libtool, чтобы всё заработало.
Есть впечатление, что опенсорс-фонаты, радеющие за кроссплатформенность, не подразумевают под кроссплатформенностью возможность сборки (и нормальной работы) под виндой.Правильно собрать развесистое кроссплатформенное приложение под виндой очень сложно. Неудивительно что многие на это забивают.
Правильно собрать развесистое кроссплатформенное приложение под виндой очень сложно.Почему же? Хотя если лениться писать нормальный кроссплатформенный код и сделать заведомо непортируемую архитектуру проекта, то быть может ты и будешь прав
Нуну.
Допустим у нас Питон+ghostscript+freeimage+libxml+libxslt и честная коммерческая лицензия.
Тогда оказывается что все эти штуки мы должны собирать из исходников, да еще и автоматически, а в винде даже make недогнутый.
Потом надо чтоб программа работала на windows 2000, XP, 2003, vista, у которых у всех свои недокументированные глюки.
Я вот такими делами и за деньги заниматься не буду, что уж про опенсорс разработчиков говорить.
Допустим у нас Питон+ghostscript+freeimage+libxml+libxslt и честная коммерческая лицензия.
Тогда оказывается что все эти штуки мы должны собирать из исходников, да еще и автоматически, а в винде даже make недогнутый.
Потом надо чтоб программа работала на windows 2000, XP, 2003, vista, у которых у всех свои недокументированные глюки.
Я вот такими делами и за деньги заниматься не буду, что уж про опенсорс разработчиков говорить.
а в винде даже make недогнутый.в чём проявляется недогнутость гнутого make под винду?
Оставить комментарий
yroslavasako
При попытке собирать софт с помощью системы msys/mingw cтолкнулся с несколькими проблемами, связанными со статическими и динамическими библиотеками. В первом случае возникшие проблемы мне удаётся решать ценой заметных усилий, и иногда патчей. Во втором случае проблемы мне показались нерешаемыми и черезвычайно трудными, так что я отложил компиляцию нестатических версий в долгий ящик.Быть может кто-нибудь уже сталкивался с ними, и сможет помочь советом.
1. Иногда выдаётся ошибка dlfcn.h: no such file o directory. (Даже при опциях компиляции --disable-shared --enable-static)
Вопрос: как избежать подобных ошибок. Вероятнее всего существует библиотека-интерфейс для инкапсуляции dlopen виндовыми средствами. Не знает ли кто как её включить в процесс сборки? А может достаточно переопределить функциональность dlopen на уровне макросов, даже не компиля специальной библиотеки?
Текущие решение: отключение фич, что никуда не годиться.
2. Собственноручно собранный libtool последней версии страдает шизофренией (прекомпилированные варианты фатально не поспевают за мейнстримом, и большинство библиотек с их помощью невозможно собрать). Libtool никак не может решить, что представляют собой суффиксы библиотек под винду. Динамические он создаёт исправно с суффиксом dll. А вот статические отличаются разнообразием: libtool колеблется между суффиксом .a и .dll.a. В результате создаются конфигурационные файлы и файлы .la смешанного содержания, где в разных графах указываются разные названия с разными статическими суффиксами. Как бы сделать так, чтобы у него перестало двоиться в глазах?
Текущее решение: после сборки из двух библиотек выбирается та, которая больше по размеру, и копируется в ту, которая меньшая. По одному, или по другому имени, но библиотека находится. Возможно появятся другие скрытые проблемы (библиотечные функции, например, будут раскиданы по разным либам, и часть функций погибнет но они пока не проявлялись.
3. Иногда libtool просто отказывается создавать динамические библиотеки. Например, в случае libxml при попытке компиляции динамической библиотеки выдаётся ошибка: undefined reference to `__imp__xmlFree. С чем это может быть связано?
Текущее решение: пока просто забиваю на динамику, если она не хочет собираться сама.
4. Libtool при создании динамических библиотек работать с символическими ссылками, создавая сразу несколько файлов с разными версиями библиотек, но в винде такие фокусы не прокатывают, и создаётся только один файл, благодаря чему сборка других программ периодически падает из-за неверного именования библиотек, другие же могут собраться, молчаливо выключив фичи, требующие корректного именования файлов библиотек. В винде на системе NTFS есть возможность создавать ссылки для файлов, как научить msys работать с ними вместо родных?
Текущие решение: забить на сужение функциональности, в случае падения сборки провешивать требуемую ссылку вручную.
Есть ещё общие проблемы с библиотеками, которые я пока решать не стал, предпочитая не пользоваться соотвтетсвующей функциональность. Они связаны с применением pkgsrc, на выяснение методики работы которого я решил пока не тратить времени. Вроде бы актуальную версию можно скачать с сайта гнома, странички закачек под винду. Не нужно ли самому собирать его? Что нужно ещё сделать, чтобы он корректно заработал? Дело в том, что я не собираю программы в собственное дерево, а имею свои директории $prefix $libdir $bindir $includedir, с которыми и работаю. Куда и насколько корректно сохраняются данные pkgsrc при компилировании не в одно дерево с общим префиксом? Покамест, я игнорирую саботаж и отключение фич, возникающие вследствие неработоспособности pkgsrc. Если же пакет не может собраться без него, я передаю всё необходимое через переменные окружения и правлю файл конфигратора (чтобы он читал данные из переменных окружения, а не из pkgsrc).