Лидеры

rebase -- мощная штука при правильном использовании: позволяет держать историю красивой (когда она состоит из комитов слияния, где чётко видна этапность добавления фич и фиксов, по такой истории легко ориентироваться -- быстро находится добавление той или иной фичи, а по комитам слитой ветки видна локальная история разработки фичи, ничего не смешивается) при работе группой. Где пригождается rebase, лучше показать на примере. У нас процесс построен так (он рекомендованный, насколько знаю): есть общая ветка разработки, она постоянная, она содержит только целостные комиты, т.е. состояние проекта таково, что он собирается и работает. Основной смысл этого в том, чтобы любой участник команды мог взять крайний комит за основу для разработки своей фичи, и у него всё будет собираться, не будет чужих ошибок, которые будут ему мешать развивать и собирать своё. Для этого создаётся временная ветка (feature branch -- FB). Сливать в общуюю ветку может только её мейнтейнер, у остальных таких прав нет (это обеспечивает целостную базу как отправную точку для всех участников проекта независимо от их дисциплинированности -- главное, чтобы ментейнер не был раздолбаем и добросовестно проверял перед слиянием -- это несложная работа, её вообще можно автоматизировать, но у нас руки пока не дошли, не обременительно запускать сборку/тесты руками). Работа участниками проекта ведётся параллельно. Когда фича готова к слиянию, её автор создаёт pull/merge request на слияние этой FB в общую. Перед этим он делает rebase на общую ветку, чтобы объединить свою фичу с кодом общей, которая за время работы над FB могла уйти вперёд (как правило так и происходит). Мейнтейнер проверяет целостность кода, запуская сборку, тесты. Если всё успешно, FB сливается в общую с комитом слияния (git merge --no-ff). Результатом будет чётко видная в истории ветка FB со всеми своими комитами, слитая в общую через комит слияния. Делать объединение общей ветки с FB обязательно -- на этом этапе вылезают всякие конфликты, ошибки и т.п. Объединять можно двумя способами: через merge и через rebase. Если делать через merge, то это нарушает описанную выше "красивость" истории (которая нужна далеко не только из эстетических аспектов, но является мощным подспорьем для ретроспективы кода). rebase позволяет держать локальную историю разработки фичи компактно и целостно, не смешивая с комитами других веток. Да, это изменяет историю развития проекта в смысле строгой хронологии, но для работы с кодом гораздо важнее вид с точки зрения добавления фич и фиксов, когда видны этапы работы, а не вид с точки зрения последовательных дат комитов. Получается, что хотя работа участниками проекта во временном аспекте ведётся параллельно, в истории комитов результаты их работы (фичи/фиксы) добавляются строго последовательно, что убирает путаницу: вид такой, как будто все работали друг за другом по цепочке, дожидаясь результата (слияния) от предыдущего члена команды. В описанном процессе rebase пригождается не толькло при работе командой. Ровно то же самое и когда работаешь один, если приходится параллельно вести больше одной FB (например, при разработке фичи отвлекаться на правку багов, создавая для них свои ветки).

паче всех человек окаянен есмь....

Дело даже не в компиляторе. На уровне языка можно только предполагать где что будет размещено. А дальше можно чем-то управлять ключами, чем-то скриптом линкера. Всё implementation dependent, так вроде в стандарте языка сказано. Ничего странного. Стандарт языка не определяет как оно под капотом должно работать. Что-то в gcc поменяли в очередной версии. Бывает. Более того, то что .noinit ведёт себя как обычная непривилегированная секция, в отличии от .bss, очень даже правильно.

PDS 2022.2 SP6.1 Windows залил в upload Release_Notes.pdf PDS 2022.2 sp6.1 innek.pdf

Попробуйте сделать отдельный таргет на каждую сборку. При желании потом можно сделать третий, вызывающий первые два друг за другом.