LTO не работает

Если ошибка в плагине LTO, то смена линкера не должна ничего менять.

Так они же исправили этот баг ещё в Gcc 8.1, какого чёрта она опять вылезла? Что за плагин? Может быть эта ошибка от неправильной сборки (я пересобирал binutils)? Может ли не подходить версия 2.30 к gcc 9?

Ответьте хотя бы почему gold не хочет запускаться, я должен попробовать этот линкер, судя по месту ошибки проблема в нём

Так они же исправили этот баг ещё в Gcc 8.1, какого чёрта она опять вылезла?

Я нашёл несколько похожих багов, но с разными номерами строк. Этот может быть другим (в ОП нету самого ассерта). А может исправили не до конца.

Что за плагин?

Плагин для линкера. При LTO объектные файлы содержат дампы translation unit и сам линкер с таким работать не умеет, поэтому компилятор предоставляет ему плагин.

Может быть эта ошибка от неправильной сборки (я пересобирал binutils)? Может ли не подходить версия 2.30 к gcc 9?

Не думаю, что это имеет значение. Это всё же ошибка не вызова утилиты, а работы части компилятора (LTO-плагина).

Ответьте хотя бы почему gold не хочет запускаться

-lugin
-lugin-opt

Должно быть --plugin и --plugin-opt. Возможно, что модный и молодёжный meson тупо вырезал вхождения -p какого-то хрена.

Когда у меня стоял gold 2.24 (поставляется со старой ubuntu), ошибок lugin не было.

Как и где эти команды исправить?

Не знаю. Да и вообще ld.gold должен вызываться самим gcc, т.е. meson не должен был повлиять. Тем более, если раньше работало. Это какая-то странная ошибка после обновления.

Хотел предложить воспользоваться аналогом strace для дерева процессов, что может показать кто и что запускает, но не получилось вспомнить название… Как бы не на ЛОРе в новостях оно было.

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

Мой тебе совет, поставь slackware current, или на крайняк arch linux / debian testing. Там нет этих страданий со старым софтом.

А я утилиту вспомнил. forkstat, называется (исходники). Запускать от рута так:

forkstat -gx

Потом выполнить попытку сборки и завершить forkstat по Ctrl-C. Может что полезное и покажет.

Кстати, ведь правильно понимаю, что когда в с++ приедут модули (ещё и std на них запилят), то компилятор/линкер сможет оптимизировать сpp+код_из_модулей как одно целое (ну и lto в таком случае как бы и не нужна)?

Думаю, что неправильно. Модули кешируют в основном интерфейс. Там может быть что-то ещё, что не публично, но основная масса кода не попадёт в бинарный файл модуля, если это не header-only.

А если бы попадало, то компиляция бы сильно замедлилась. При этом место для LTO осталось бы, так как оно оптимизирует всё единицы трансляции вместе, а не по отдельности.

Дело в том, что как-то тестил модули на clang, сделал модуль с функцией, в цпп вызывал в цикле. В итоге функция из модуля заинлайнилась, т.е. оптимизатор поработал. С другой стороны, никакой официальной инфы нет, никто на оптимизации+модули акцент не делает. Может у шланга оно так случайно получилось и это вообще необязательно )). Думаю, что это нужно прям сейчас на уровне стандарта обязать компиляторы оптимизировать сквозь модули.

модули на clang

Это могли быть их модули, а не те, которые приняли. Но в любом случае, если тело функции в заголовке/интерфейсе, то инлайн будет работать. Если же там только объявление, то инлайна не будет. В этом плане ничего не поменялось.

Ну я уже не очень помню, но пробовал модули примерно так (пример из стековерфлоу, помню его):

// file: foo.cppm
export module M;
export int f(int x){
    return 2 + x;
}
export double g(double y, int z){
    return y * z;
}

// file: bar.cpp
import M;
int main(){
    f(5);
    g(0.0, 1);
    return 0;
}

$ clang++ -fmodules-ts --precompile foo.cppm -o M.pcm
$ clang++ -fmodules-ts -c M.pcm -o M.o
$ clang++ -fmodules-ts -fprebuilt-module-path=. M.o bar.cpp

Это принятые модули и полностью определённые в одном файле, тут компилятор всё видит (кажется, можно сделать секцию, чтобы видел не всё).

LTO может замедлять, если из-за встраивания код сильно раздувается. Т.е. дело не в самом LTO, модули это никак не решат.

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

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

cd папка_исходников_binutils

mkdir -v build

cd build

../configure –prefix=/usr –enable-gold –enable-ld=default –enable-plugins –enable-shared –disable-werror –enable-64-bit-bfd –with-system-zlib

make tooldir=/usr

make -k check

make tooldir=/usr install

Файлы устанавливаются в /usr/i386-pc-linux-gnu, нужно вручную вырезать их оттуда и вставить в /usr/bin и /usr/lib/i386-linux-gnu, под рутом. Ещё можно сделать симлинк для удобства:

ln -s /usr/bin/ld.bfd /usr/bin/bfd ln -s /usr/bin/ld.gold /usr/bin/gold

Ах да, забыл, надо не

make tooldir=/usr install

А по другому, с sudo:

sudo make tooldir=/usr install