Всем здравствуйте.
Осваиваю ланчпадавский компилятор. Столкнулся с тем, что при включенной Lto не видит функции, например sqrt(), из math.h. "undefined reference to `sqrt'
collect2.exe: error: ld returned 1 exit status".

Compile opts -mcpu=cortex-m3 -flto -lto -mthumb -fpack-struct -Wpadded -g -Os
Linker opts -mcpu=cortex-m3 -flto -mthumb -Wl,--gc-sections,-Map=Project.elf.map,-cref,-u,Reset_Handler

Target CPU STM32F103RET6
gcc-arm-none-eabi-5_4-2016q3-20160926-win32

Подозреваю, что дело в ключах, но не знаю в каких. Очень надеюсь на ответ.

Вроде бы ещё надо линкеру передать ключ оптимизации (-Os)

Не, дело было не в этом. Вчера наконец-то разобрался. Почему-то -Lto выкидывает библиотеку m. Я прописывал -lm, но это не помогало потому, что lm надо прописывать в самом конце, после перечисления всех о-файлов, а я писал вначале. Почему это происходит - непонятно...

А, ну это известная штука. Понять этого нельзя, поэтому надо запомнить

Разумеется. По умолчанию включено --as-needed.

Прочитал доку про --as-needed и для меня не совсем очевидно описанное ТС поведение (откидывание libm).
Я понял, что линкер должен выкинуть лишь те либы на которые нет ссылок.
Поясните пожалуйста, если не трудно, что я не так понимаю.

Понял кажется!
Если либа включена до объектиников, то на момент её линковки на неё просто ещё нет ссылок.
Линкер видимо по умолчанию однопроходный.

Кстати, для решения сложных циклических завязок либа от либы есть ключики --start-group --end-group

да, злостная шутка с этими линкер-опциями и порядком подключения библиотек.

Это избавляет от излиших связей. Если бибилиотека по факту не используется, то линковаться с ней не надо, несмотря на то, что она почему-то указана в списке на линковку. Так что какие уж шутки.

См. https://www.altlinux.org/UpStream/AsNeeded

Всего этого можно достичь (и полно линкеров, которые это умеют.., да, по ходу, все кроме гнутого умеют) и без этой дурацкой фичи: либо сделать обработку двухпроходной, либо разрешение связей не делать непосредственно в процессе чтения данных - например, сперва все данные читаются, потом, когда вся оперативная информация в наличие, производится разрешение связей. Гнушный линкер просто 1) однопроходный, 2) производит обработку связей непосредственно во время чтения файлов, т.е. если библиотека указана раньше объектного файла, из которого есть ссылка на библиотечный объект, то из библиотеки ничего не линкуется.

А ничего, что тут весь тулчейн GNU? Вы предлагаете заменить GNU ld на какой-то другой? И всякие configure.ac и Makefile.am патчить тоже предлагаете? Ну круто, чо.

Где вы увидели предложение что-то менять? Я сказал лишь то, что есть и другие способы реализовать выкидывание ненужных объектов, свободные от зависимостей, возникающих от порядка указания библиотек. Кстати, даже если представить, что ld вдруг исправят и его поведение в части подключения библиотек не будет зависеть от порядка их указания, это ничего не сломает и ничего править не придётся.

Во-первых, уже ничего исправлять не будут. Такое поведение есть уже исправленное. Во-вторых, старое поведение по-прежнему доступно при указании --no-as-needed. Но оно ненужно. Все апстримы уже давно исправились.

Андрей, вы б послушали, что dxp говорит...

Выкидывать неиспользуемые библиотеки - это хорошо, и с этим никто не спорит.
Однако сам механизм определения "неиспользуемости" в ld сделан неидеально (даже ваша ссылка на шаманские действия с альтлинуксом это подтверждает).

Конкурирующие организации почему-то сделали этот механизм лучше (никогда не задумывался, как - там оно просто РАБОТАЛО).

Ещё раз. У нас есть тулчейн имени GNU. Линкер там работает так, как работает.
Да существеут куча других тулчейнов, в которых линкеры рабоают по-другому. Но причём тут они, зачем о них тут писать?

Ответов по делу тут два: #6 от demiurg_spb (что делать и где читать) и #9 от dxp (с объяснением, что там "внутри").
Спасибо за оба, кстати: раньше я просто менял местами инклюды.

И какой-то флуд на тему "у меня всё работает, проблемы на вашей стороне" (не буду пальцем показывать).
Слава богу, gcc - это не нечто, отлитое в граните в полночь 1.01.1970, и он худо-бедно развивается. Будем надеяться, и здесь допилят тоже...

Зато GNUшный линкер быстрый!