LINUX.ORG.RU

Порядок линковки библиотек


0

2

Столкнулись со следующей проблемой. Есть софт который собирается с использованием (не даст бог соврать) 20 сторонних библиотек, половина из которых это один большой проект, еще часть это буст и еще пара своих, и это все хитроспелетено между собой.

И вот все это чуду перестало собирается после добавление пары новых библиотек (из другого проекта). По причине undefine bla bla bla.

Постепенно удалось восстановить последовательность библиотек при которой все слинковалось. Но вот проблемы, эта последовательность сделана руками из строки для компоновки которую создал CMaka. СMake создает избыточность в этой строке дублируя часть библиотек. Это я думаю все решаемо.

Хотелось бы узнать поподробней про процесс линковки теперь, почему вообще такая проблема появляется. Почему линковщик не строит граф зависимостей на лету и не вычисляет что после чего надо линковать. Ведь для него вся эта информация доступна из самих библиотек. Ведь под виндой такой проблемы нет, получается VS делает это.

Может есть отдельные софт которому можно скормить либы и он построит сей граф и визуально или как угодно покажет что от чего зависит ?


Порядок линковки библиотек

все хитроспелетено между собой


Что тут можно сказать... Переработайте архитектуру так, чтоб не зависела от порядка. :) Вообще, о разрешении зависимостей лучше думать до, а не после. Про процесс линковки посмотри тут http://webcache.googleusercontent.com/search?q=cache:DaP8AE50PbAJ:www.yolinux...

slackwarrior ★★★★★
()

Ведь под виндой такой проблемы нет, получается VS делает это.

Возможно, твой случай - зависимость от порядока линковки с удвоенными зависимостями и это самое «нет проблем под виндой», как раз из-за того, что собрка завязана на виндовую особенность разрешения зависимостей индивидуально для либ и исполняшки, как указано по ссылке в разделе Comparison to the Microsoft DLL: [Potential pitfalls] (Выделено красным). Т.е. софт, хотя и собирается при помощи cmake, разрабатывался абсолютно без оглядки на кроссплатформенное разрешение зависимостей, которое как раз скриптами для cmake разруливается при нормальном проектировании.

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

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

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

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

ссылку вкурю. Это возникло в процессе портирования проекта на новую версию либ. Из за чего появились новые зависимости которые были просто добавлены в cmake скприты. Я до этого момента даже и не думал что такая проблема может существовать (не спорю, и за полного отсутствия знания процесса линковки)

Когда ты используешь разные наборы библитек(фраемфорки) ты не можешь предугадать как они изменятся в будущем. Да ты и на настоящее их не можешь повлиять. А если еще и так что один пишется на основе другого (кемнить) а третий эти оба еще использует...

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

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

Когда ты используешь разные наборы библитек(фраемфорки) ты не можешь предугадать как они изменятся в будущем.

Эту проблему следует хотя бы иметь в виду. Некоторые включают в ТЗ раздел «управление рисками» и стараются их если не исключать, то минимизировать (главное, перед началом чего-тоделания эти риски распознать и куда-то записать, а так же ответы на вопросы «а что мы будем делать, если...») Что касается кроссплатформы - тут в книжках по проектированию обычно советуют не делать никаких предположений о компиляторе и зависимостях, точнее, предположения переводить в явные требования. В общем, не программировать «в вакууме».

slackwarrior ★★★★★
()

СMake создает избыточность в этой строке дублируя часть библиотек.

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

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

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

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

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

Когда я руками строку компоновки правил, я избавился от всех дубликатов. Как такое сделать в Cmake... я хз :( я даже не понимаю откуда там появляются дублирующиеся зависимости.

Если я в конечном Cmake делаю targen_link_library и add_subdirectory там нету. А при выполнении у меня к этому проекту добавляются зависимости из других скриптов Cmake которые либо на том же уровне либо ниже. Но не как не включаются. Но это уже другая проблема.

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

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

cmake обеспечивает это следующим образом: если для некой библиотеки указаны target_link_libraries, то всякий раз как производится линковка с этой библиотекой, cmake рекурсивно добавляет в линковку все библиотеки, от которых она зависит.

Мне казалось, что дубликаты cmake автоматом разруливает. Но, судя по тому, что ты тут пишешь, это не так. Ну и пофиг, все равно это ни на что (почти) не влияет.

а зачем они нужны ?

Механически так получилось.

В мире полно бесполезных вещей. Бесцельное избавление от бесполезных вещей - это само по себе такая же точно бесполезная вещь. Глупо вкладывать в нее свои силы и время.

Manhunt ★★★★★
()

Если не думая, то

ld -( -llib1 libstatic.a -llib2 -)

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