Ну заведи баг на gcc, или тебе тупо поныть надо?

Разве сейчас нет почасовой аренды серверов? Арендуй себе с любым количеством памяти, да собирай удалённо...

с Clang,а он глючит

Кто глючит? Хромиум, или шланг? Если шланг, то стукнись мне в жаббер.

Это не баг GCC, а фича. Т.е. получается всё равно долго, т.к. либо в мало потоков, либо отключать jumbo-build.

Глючил Хромой. Собрал Ungoogled. Всё работает.

А разве не выпилили в последних версиях хрома возможность сборки GCC? Я помню, у меня бомбило знатно.

А по поводу памяти, так в GCC опитимизация результата лучше, а все эти плюшки кушают память в процессе сборки. И с чего бы сборка в три потока должна кушать меньше памяти чем в один?

А разве не выпилили в последних версиях хрома возможность сборки GCC?

в Дженте собирается, и работает.

А по поводу памяти, так в GCC опитимизация результата лучше, а все эти плюшки кушают память в процессе сборки.

Фича в том, что в Clang всегда включён ThinLTO, а с GCC собиралось без LTO.

И с чего бы сборка в три потока должна кушать меньше памяти чем в один?

А разве не должна?.

А разве не должна?

Занятная у тебя арифметика: 3·x = x/3!

не так слова поставил в предложении при его прочтении.
Clang в 9 потоков - 16 ГБ хватает и для браузера.
GCC в 3 потока - 16 ГБ еле хватает для сборки.

Пробую собрать с GCC, а ему GCC 16 ГБ становится мало

Ну заведи баг на gcc, или тебе тупо поныть надо?

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

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

Хотя в 8.2 вроде исправили, ну всё как обычно. Или у него 9? Первая версия всегда сырая.

это ж разные компиляторы, у них разное внутреннее представление данных и тэдэ и тэпэ. а что ты хотел то?

LTO там не причем (в баге). И насколько помню даже тип исходника (си или си++) не причем. Просто gcc стал резко прожорлив. Вроде, в 5.x перешли на с++, также добавили всякие разные оптимизаторы на графитах.

Просто gcc стал резко прожорлив.

Он и в 4.х был прожорлив по памяти

Насколько я помню, внезапная прожорливость была связана именно с лто и линкером — жирнолис внезапно стал в 4 раза больше потреблять на сборке (при том что лто и так жрал слишком много). Потом это всё исправляли.

Возможно мы про разные версии думаем.

Пробую собрать с GCC, а ему GCC 16 ГБ становится мало.

Ну это не новость.

Делаю сборку в 3 потока, всё равно мало.

Попробуй без -pipe
А своп религия не позволяет?

Можно было бы SWAP-file попробовать заюзать.

Он и в 4.х был прожорлив по памяти

Помню, что при переходе на 5.х gcc стал заметно требовательне по памяти.

в Дженте собирается, и работает.

видать запилили обратно

Ага, засвопилось бы 10+ гигов, которое обратно в память вернулось бы и возобновило компиляцию только через полчаса (это если своп на ssd, на hdd - вообще сутки).

У меня есть код, который в gcc компилится и работает, а в clang компилится и падает. Я к тебе в джаббер стукнулся.

Быстрый поиск в багтрекере нашел https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563. Но вот помню, был похожий баг для 5.х. Но не могу найти

Собираю значит Chromium как обычно с Clang,а он глючит.

Надо было firefox собирать, не в компиляторе дело в данном случае.

/thread

как раз в нём,кмк

Жирно почему-то лис, а памяти почему-то хромому не хватает.

либо в мало потоков, либо отключать jumbo-build.

Ну так пропатчи ninja, чтоб следила за /proc/meminfo:MemAvailable и не запускала задачу, если мало. Заодно make. И будет тебе мало потоков, когда нужно.

ты раз в полгода создаёшь подобный тред, и каждый раз тебе говорят нафига его собирать и раз в полгода ты отвечаешь — потому что я компилю все подряд. /thread

я понимаю фф компилить из-за фичастых custom-optimization, а смысл юзать хромимум если все равно заходишь под акком гугла, который сливает все и вся, если боишься зондов фф, если не боишься то хром-bin.

Хромиум собираю со всякими патчами

А по поводу памяти, так в GCC опитимизация результата лучше, а все эти плюшки кушают память в процессе сборки

С какого это боку? Тесты разработчиков Хромого и Лисы говорят об обратном.

Это ты все просто для холиваров? nice для слабаков?

Я ФФ с 2 ГБ оперативки собирал, swap настрой.

Ссылку на тесты в студию.

Да, что-то я такого не видел.

Мне лично похер сколько там оно собирается, лишь бы программа работала потом быстро.

Я такого же мнения, поэтому предпочитаю GCC. Clang хоть и собирает быстрее, но результат работает медленнее, так что в топку его.

https://glandium.org/blog/?p=3888

Предлагаю взять какой-нибудь бенч на CXX и собрать его gcc с -O3, lto и pgo. Ну и его же собрать шлангом с теми же lto и pgo. Проверить командой time на машине без иксов и прочей фоновой хрени.

Вот это будет тест, а этот бложек - сомнительное доказательство превосходства clang.

Сравнение производительности firefox, собранного gcc без LTO и clang с LTO. А собрать с помощью gcc с LTO он не осилил. Ну чтож, well done.

Тест сферической синтетики в вакууме для аутистов-цифродрочеров.

GCC+PGO vs. clang+PGO was a win for clang overall in both cases
clang without PGO/LTO was also winning against GCC without PGO

it seemed a better deal to switch to clang than to try to address those issues.

Как-то вообще печально с этими ребятами. gcc 6 далеко не самый лучший вариант, но свежий gcc они заюзать не могут, так как код кривой. А проще компилятор поменять, чем код починить.

И для юзания lto под шлангом врубили везде pie, который оптимизациям мешает.

вообще пофиг.

В Дженте врубили PIE по умолчанию. Можно, конечно, разбанить, но чё-то ломает опять всё пересобирать.

врёти

резкий довод, не, ну, а, чо.

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

Ну а чо. Что там без LTO и PGO меня вообще не волнует.

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

Ты о msvc, когда говоришь о забивании гвоздей киянкой?

сорри, нубский вопрос

а смысл и цель самосборки, если есть бинари в репах?

Разве не в харденед только?

нет, везде.

2017-11-30-new-17-profiles
  Title                     New 17.0 profiles in the Gentoo repository
  Author                    Andreas K. Hüttel <dilfridge@gentoo.org>
  Posted                    2017-11-30
  Revision                  1

We have just added (for all arches except arm and mips, these follow
later) a new set of profiles with release version 17.0 to the Gentoo 
repository. These bring three changes:
1) The default C++ language version for applications is now C++14.
   This change is mostly relevant to Gentoo developers. It also
   means, however, that compilers earlier than GCC 6 are masked 
   and not supported for use as a system compiler anymore. Feel 
   free to unmask them if you need them for specific applications.
2) Where supported, GCC will now build position-independent
   executables (PIE) by default. This improves the overall
   security fingerprint. The switch from non-PIE to PIE binaries,
   however, requires some steps by users, as detailed below.
3) Up to now, hardened profiles were separate from the default
   profile tree. Now they are moving into the 17.0 profile
   as a feature there, similar to "no-multilib" and "systemd".

Please migrate away from the 13.0 profiles within the six weeks after
GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles
will be deprecated then and removed in half a year.

If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps: 
If not already done,
* Use gcc-config to select gcc-6.4.0 or later as system compiler
* Re-source /etc/profile:
    . /etc/profile
* Re-emerge libtool
    emerge -1 sys-devel/libtool
Then, 
* Select the new profile with eselect
* Re-emerge, in this sequence, gcc, binutils, and glibc
    emerge -1 sys-devel/gcc:6.4.0
    emerge -1 sys-devel/binutils
    emerge -1 sys-libs/glibc
* Rebuild your entire system
    emerge -e @world

Switching the profile from 13.0 to 17.0 modifies the settings of 
GCC 6 to generate PIE executables by default; thus, you need to do 
the rebuilds even if you have already used GCC 6 beforehand.
If you do not follow these steps you may get spurious build
failures when the linker tries unsuccessfully to combine non-PIE
and PIE code.

[ebuild   R    ] sys-devel/gcc-8.2.0-r5:8.2.0::gentoo  USE="cxx graphite nls nptl openmp pch pgo (pie) (-altivec) -debug -doc (-fixed-point) -fortran -go (-hardened) (-jit) (-libssp) -mpx (-multilib) -objc -objc++ -objc-gc -regression-test -sanitize -ssp -systemtap -vanilla -vtv"