Порядок компиляции файлов Опции

[sergey sva]

Для компиляции исходников используется маке файл в gcc, Во время написания маке файла возник
вопрос, в каком порядке лучше компилировать файлы?, попробовал очередность поменял ошибок нет,
в сети поискал, не чего нужного не нашел, может есть какие рекомендации ?

[ARV]

АБСОЛЮТНО безразлично.

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

[MrYuran]

или компоновщик более интеллектуальный и тасует секции (если можно, конечно) уже после компиляции сам?
вообще, есть смысл в моих размышлениях или они надуманы?

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

[ReAl]

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

--combine --whole-program
combine для того, чтобы все перечисленные в командной строе исходники собрать в один объектник (сначала объединив в один исходник) а whole-program - чтобы рассматривал это как уже законченную программу. Благодаря этому неиспользуемые функции выбрасываются ещё не доходя до --gc-sections, мелкие функции "из другого файла" инлайнятся по месту и их отдельное тело выбрасывается (раз это уже вся программа, значит снаружи никто не вызовет) и т.д.
Вот только некоторые проблемы возникают, если в проекте есть асм-файл и он вызывет что-то из С-файла. С точки зрения собранных в кучу С-файлов та функция не вызывается вообще, поэтому она выбрасывается из файла а_тут_собраны_все_с.o и не находится при линковке.
Должно лечиться атрибутами used и externally_visible для той С-функции, которая вызывается из асм-файла, но пока не проверял, не очень зудит таким путём пытаться ещё уменьшить размер бинарника.

Да, аналогичная беда должна возникать при миксе С и С++, лучше и чисто-С-шные вещи тоже обрабатывать как С++, чтобы пошло на вход одного компилятора.