44106 2022-10-21 12:57:14 +0300 прибитый гвоздями уровень оптимизации -O2 2023-06-07 08:18:40 +0300 1 1 4 Development Sisyphus cmake unstable all Linux NEW P4 minor --- 1 mike lav arbars ilyakurdyukov iv lav ximper zerg qa-sisyphus oldest_to_newest 216283 0 mike 2022-10-21 12:57:14 +0300 По состоянию на cmake 3.23.2-alt1.1 в /usr/share/cmake/Modules/Compiler/ наблюдаю прибитые гвоздями -O2 -- как если бы этого было мало, опции по умолчанию эти люди передают _после_ того, что указал собирающий, т.е. наши %optflags попросту перекрываются, если не предпринимать особых cmake-специфических мер. На x86 это некритично, поскольку совпадает с типичным применением gcc; на e2k -- уже существенно, поскольку для lcc в rpm-build выставляем по умолчанию -O3. Может оказаться важно и для других архитектур. В 3.23.2-alt1.2 добавил под %ifarch %e2k: sed -i 's/ -O2/ -O%_optlevel/g' Modules/Compiler/{LCC,GNU}* Возможно, стоит вытащить из-под %ifarch (и заодно трогать Clang*). Если вдруг у кого есть контакт с апстримом -- им бы как-то довести, что дефолты -- на то и дефолты, чтоб при необходимости _их_ можно было перекрыть, а не _они_ перекрывали указанное явно... Спасибо Илье Курдюкову за обнаружение и доведение до моего сведения. 216287 1 iv 2022-10-21 13:31:24 +0300 На mipsel для некоторых пакетов приходится выставлять %ifarch %mips32 %define optflags_debug -g1 %endif так как с простым стандартным -g компилятор ест слишком много памяти и не помещается в 2Gb юзерспейсного виртуального адресного пространства 32-битного mips. Так вот, для некотрых пакетов я добавлял к аргументам %cmake дополнительные флаги. Например, к libopencv так: -DPYTHON_DEFAULT_EXECUTABLE=%__python3 \ + -DCMAKE_C_FLAGS_RELWITHDEBINFO="%optflags" \ + -DCMAKE_CXX_FLAGS_RELWITHDEBINFO="%optflags" \ %nil Я тогда начинал писать письмо, но не отправил, так как не доразобрался, это у libopencv такой странные CMakefile'ы или проблема более глобальна. Видимо, глобальна. Выводы из этого: 1. sed'а не достаточно, хотелось бы полного применения %_optflags в том виде, как они в спеке. 2. Всё можно настроить. Я подозреваю, что в приоритете применения настроек у cmake есть своя логика, но и с ней можно подружится. Для этого предлагаю добавить в %cmake дополнительную кучу настроек и посмотреть, поможет ли. Примерный список на добавление: CMAKE_C_FLAGS_DEBUG=%_optflags \ CMAKE_C_FLAGS_MINSIZEREL=%_optflags \ CMAKE_C_FLAGS_RELEASE=%_optflags \ CMAKE_C_FLAGS_RELWITHDEBINFO=%_optflags \ CMAKE_CXX_FLAGS_DEBUG=%_optflags \ CMAKE_CXX_FLAGS_MINSIZEREL=%_optflags \ CMAKE_CXX_FLAGS_RELEASE=%_optflags \ CMAKE_CXX_FLAGS_RELWITHDEBINFO=%_optflags \ CMAKE_Fortran_FLAGS_DEBUG=%_optflags \ CMAKE_Fortran_FLAGS_MINSIZEREL=%_optflags \ CMAKE_Fortran_FLAGS_RELEASE=%_optflags \ CMAKE_Fortran_FLAGS_RELWITHDEBINFO=%_optflags 216706 2 lav 2022-10-30 18:10:10 +0300 Чтобы провести эксперимент, хорошо бы иметь патч к cmake и проект, на котором проверять. В идеале хотелось бы, чтобы эксперимент провёл кто-то более заинтересованный, чем я. Ну и общение с апстримом тоже. Они там мало воспринимают жалобы, но готовое исправление может их убедить.