Автоматическое разруливание (очерёдность линковки) зависимостей системой сборки\линковщиком

и хочу их слинковать вместе

-Wl,--start-group -lx -ly -lz -Wl,--end-group

Потому что кресты и сишка созданы 100500 лет назад. Тогда это было норм.

-lx -ly -lx

Я линкер руками уж 100 лет не запускал. Это не опечатка?
Ты предлагяешь рандомно(?) руками(?) повторять либы пока они не слинкуются?

-lx -ly -lz

Ок, опечатка таки. Но если линкер умеет, то по какой причине CMake этим не пользуется?

Очевидно же, что потому что ты не прислал патч

https://github.com/Kitware/CMake/blob/251c1fc56c2c40c4a16b1e3dd1ffee5f1f38b3e8/Source/cmComputeLinkDepends.cxx#L35

?

По ссылке подробно описано как cmake строит граф зависимостей. Если у тебя есть идея как сделать лучше, пришли патч (открой реквест, хотя бы опиши словами в issue). А так ты просто ноешь.

Насколько я вижу не вникая в тему, они даже не пытаются выяснить какие «символы» в каком бинарнике. Они строят свои предположения отталкиваясь лишь от содержимого конфига.
Или я чего-то не вижу?

О, кроме костыля

target_link_libraries(main PRIVATE -Wl,--start-group ${LIBRARIES} -Wl,--end-group)

есть ещё костыль с указанием сколько раз пытаться линкануть

LINK_INTERFACE_MULTIPLICITY, IMPORTED_LINK_INTERFACE_MULTIPLICITY

Repetition count for STATIC libraries with cyclic dependencies.

When linking to a STATIC library target with cyclic dependencies the linker may need to scan more than once through the archives in the strongly connected component of the dependency graph. CMake by default constructs the link line so that the linker will scan through the component at least twice. This property specifies the minimum number of scans if it is larger than the default. CMake uses the largest value specified by any target in a component.

Еще один пост про неосилил? И опять без примеров.

Почему я в том же CMake до сих пор вынужден руками определять зависимости?

Потому что CMake устарел и надо использовать Meson. Он умеет автоматически решать указанную проблему.

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

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

Вот только у меня сложилось спечатление что CMake – устоявшийся стандарт.

Некоторые и Autotools считают устоявшимся стандартом…

Нет. Стандарт это Makefile для make, только большинство его не осиливают и используют всякую дичь вроде cmake.

Я линкер руками уж 100 лет не запускал.

Вот учись.

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

См. Beginner’s Guide to Linkers.

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

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

Речь идёт о зависимостях между символами, а не библиотеками. Также имеет значения в каких объектниках символы лежат в случае статических библиотек, используются ли отдельные секции для каждой функции и т.д.

Ну я и говорю что нам нужен лишь список символов и в каких конкретно они лежат объектниках. Зачем держать сами объектники?

Детали форматов я не знаю, но метаданные объектников в них же и хранятся в ELF. И обработка каждого следующего объектника может потребовать символ из произвольной библиотеки. Вот и получается, что они нужны подольше, ну или надо копировать данные обо всём, что не используется.

Есть посты от автора GNU gold https://www.airs.com/blog/archives/38, может там есть ответ. Кстати, интересно как это делает самый современный mold.

Я всё равно не понимаю куда ты клонишь. Берёшь объектник, выколупываешь оттуда «метаданные» и дальше с ними работаешь.

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

Вот расскажите, кто собаку съел на линковке, почему до сих пор приходится руками играться с очередностью линковки?

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

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

ps:

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

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

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

Так ты попробуй собирать большие проекты, эффективность и по времени и по памяти тут как раз важна. Особенно, если учитывать, что команда линковки пишется один раз, а исполняется 100500.

Вообще, в каких-то дистрибутивах добавляли -Wl,--start-group в spec-файлы, но потом, кажется, перестали.

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

Так всегда говорят до тех пор пока не связываются со сборкой например какого-нибудь ядра, браузера или игры на не самом мощном железе. А потом ноют, а пачаму усё собирается 24 часа, а не 24 секунды.

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

То есть тебе тяжело написать

target_link_libraries(nomenus-rex AnyOption Rules Tests Progressator config++)
target_link_libraries(nomenus-rex ICU::data ICU::i18n ICU::uc ICU::dt)

И это должен сделать Cmake?

Я недавно был вынужден менять последовательность этих библиотек. Это должен был сделать Cmake.

У меня такое было с qmake, в случае со старым линкером из GCC 5.4. Это особенность, о которой уже позабыли.

It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. If bar.o refers to functions in z, those functions may not be loaded.

Cmake предполагает, что для каждой target заданы зависимости. И это в конечном итоге определяет в какой последовательности они будут поданы на вход линкера. У тебя несколько статических библиотек и приложение, но только для приложения указаны зависимости. Вот Cmake и не сдюжил.

Почему разработчики Cmake не сделали поиск символов в библиотеках? Скорее всего ограничение связано с кроссплатформенностью и кросмкомпиляторностью.

Что приводит к забавному вопросу: а что вообще делает эта махина? Просто сравнивает дату изменения исходника со временем создания бинарника? Не маловато ли будет? Может всё-таки было бы неплохо начать помогать программисту, а не лишь озадачивать его ребусами?

После небольшого изменения в коде, линкер стал ругаться на невозможность найти конструктор\деструктор одного класса, который я добавил. Я сначала подумал что я чего-то наворотил и насоздавались методы по умолчанию. Или наоборот, перестали создаваться. Или ещё что. Потом глазами смотрел в бинарики чтобы убедиться, что ф-ции таки есть. Это заняло кучу времени и ещё больше нервов.

В итоге оказалось что нужно переставить местами названия библиотек в конфиге. Причём у меня всё равно остался вопрос как это РАНЬШЕ работало. Но я уже приучился не задавать вопросы, связанные с CMake, потому что ответов обычно нет. Вразумительных, во всяком случае.

Это нехорошо.

Вразумительный ответ уже звучал. Цель Rules имеет зависимость от ICU, но в конфиге это не показано. Под Windows (допустим, что проект кроссплатформенный) сборка этой цели завершилась бы ошибками компиляции из-за отсутствующих заголовочников. Потому что цель в Cmake может содержать не только пути к библиотеке, но и пути к заголовочникам и опции компиляции. Так вот в Linux эта цель компилируется потому, что заголовочники лежат, как правило, в одном месте, о котором компилятор знает. А в Windows библиотека и заголовочники могут быть где попало. И если find_package находит библиотеку, то находит и заголовочники. И эта одна из причин, почему нужно явно указывать зависимости.

Не очень понятно, как по твоему cmake должен искать символы. Вот в своём коде я написал

extern Foo bar;

Где искать реализацию?

Не совсем понятно, где я говорил, что Cmake ищет символы.

Вот здесь:

Почему разработчики Cmake не сделали поиск символов в библиотеках?

То есть предьява за то, что я не озвучил все причины?

Не используй С и С++.

Где искать реализацию?

CMake знает о всех библиотеках, которые пользователь подключает. Как внутренних, так и внешних. Вот в масштабе этих библиотек пусть и ищет. А если не найдёт, значит пользователь что-то забыл и ему об этом нужно сообщить.

CMake знает о всех библиотеках, которые пользователь подключает.

Вот смотри: foo_linux.cpp, собираю в liblinux.a

void foo() { // linux specific code }

foo_bsd.cpp, собираю в libbsd.a

void foo() { // bsd specific code }

main.cpp

void foo();
int main() { foo(); }

Что подключать?

Просто беседуем же.

В таких случаях можно спросить у пользователя. А в 99% других случаев, когда всё однозначно – не спрашивать.

И вообще, я изначально говорил про очерёдность скармливания библиотек линковщику.

в 99%

очерёдность скармливания библиотек линковщику не имеет значения. В остальных - можно попросить пользователя использовать start-group/end-group.

очерёдность скармливания библиотек линковщику не имеет значения.

Имеет. И тред именно об этом.

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

Читай целиком. В 99% не имеет.

Это что, документацию читать? Чукча не читатель.

Но ведь тред именно об этом: зачем указывать то, что машина в 99% случаев может высчитать самостоятельно?

Да ничего не мешает, просто за >10 лет никто так и не придумал как это сделать.

https://gitlab.kitware.com/cmake/cmake/-/issues/12435

Видимо тебя ждали.

Видимо тебя ждали.

Видимо CMake не привязан к С++ и на плюсовые проблемы им просто плевать. Так что пусть ждут дальше.

И это будет выглядеть так

• Cmake пытается собрать Rules/ruleFilename.cpp и валится с ошибкой, потому что ICU из дистрибьютива староват и поэтому самособранный ICU лежит в /opt.

• Cmake парсит вывод компилятора и понимает, что нужен заголовочник unicode/unistr.h, затем ищет его и находит в ICU.

  И конечно Cmake умеет парсить не только GCC, но и других тулчейнов.

• Нужный путь добавлен и Cmake опять пробует скомпилять.

• На этапе линковки те же пляски.