Стоит ли обновлять GCC?

По тестам с каждым последующим релизом GCC производительность программ, собранных им увеличивается (не мильно конечно, но факт). Небольшой "провал" был при переходе 3 -> 4, но это пофиксили. Хороший прирост производительности ожидается в 4.4.

Так что да, обновлять стоит.

А вы уже провели сравнительное тестирование?

Если собрать программу с помощью 4.3.Х, то на целевой системе тоже должна быть установлена версия 4.3.Х. Иначе ваша программа просто не запустится.
Речь о C++, с программами на C проблем нет.

*не сильно

> Если собрать программу с помощью 4.3.Х, то на целевой системе тоже должна быть установлена версия 4.3.Х. Иначе ваша программа просто не запустится.
> Речь о C++, с программами на C проблем нет.

Разве там ломали ABI? Не должны были вроде.

> Если собрать программу с помощью 4.3.Х, то на целевой системе тоже должна быть установлена версия 4.3.Х. Иначе ваша программа просто не запустится.
> Речь о C++, с программами на C проблем нет.

Только что проверил на одном своём исходнике: бинарник, собранный с GCC 4.3.3 запускается и нормально работает на системе, на которой стоит только GCC 4.1.2. А вот при переходе от GCC 3 к GCC 4 у libstdc++ ABI действительно поломали.

Слыхал, что некоторые программы не хотят собираться с GCC 4.3.X, сталкивались ли вы с этим?

> Слыхал, что некоторые программы не хотят собираться с GCC 4.3.X, сталкивались ли вы с этим?

Известные мне эпичные случаи (virtualbox только с 4.2 собирался, а qemu только с 3) пофикшены. А по мелочам обычно в дистрибутивах мэйнтейнерами патчики накладываются.

И ещё: необходимо ли сначала пересобрать system а уже потом world? Неужели нельзя сразу world, чтоб 2 раза одно и тоже не компилить?

Спасибо, успокоили =) Обновляюсь до 4.3.3

> И ещё: необходимо ли сначала пересобрать system а уже потом world? Неужели нельзя сразу world, чтоб 2 раза одно и тоже не компилить?

Можно вообще ничего не пересобирать, а можно пересобирать в любом порядке. В пределах мажорной версии (4) ABI не ломают, так что никаких несовместимостей появиться не должно*.

* Правда возможны случаи с кривым софтом 8).

> Спасибо, успокоили =) Обновляюсь до 4.3.3

Только оставь 4.1.2 на всякий пожарный, чтобы в случае чего можно было переключиться на него через gcc-config.

> Слыхал, что некоторые программы не хотят собираться с GCC 4.3.X, сталкивались ли вы с этим?

Как пример qemu.

> Только что проверил на одном своём исходнике: бинарник, собранный с GCC 4.3.3 запускается и нормально работает на системе, на которой стоит только GCC 4.1.2. А вот при переходе от GCC 3 к GCC 4 у libstdc++ ABI действительно поломали.

Одной из причин отката на 4.1.2 была именно несовместимость. До этого стоял gcc-4.3.2 - софт не работал на системах с 4.1.2. В системе до сих пор остался софт, который не работает. Потихоньку пересобираю то, что необходимо в данный момент.

Вот пример утилиты, собранной с 4.3.2:

$ ./test
./test: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./test)

> Вот пример утилиты, собранной с 4.3.2:

Хм... А можно увидеть исходник? Если он конечно не очень большой и не сильно секретный =).

>Слыхал, что некоторые программы не хотят собираться с GCC 4.3.X, сталкивались ли вы с этим?

Да, но редко. Сейчас навскидку не вспомню, что не собиралось и ради чего приходится держать вторым слотом GCC 4.1.2

> Хм... А можно увидеть исходник? Если он конечно не очень большой и не сильно секретный =).

Ничего секретного, но там только stl.

>И ещё: необходимо ли сначала пересобрать system а уже потом world? Неужели нельзя сразу world, чтоб 2 раза одно и тоже не компилить?

Можно воспользоваться чем-то навроде:

#!/bin/bash

PCKGS=""
for i in $(find /var/db/pkg -maxdepth 2 -mindepth 2 |grep -vP 'gentoo-sources'|grep -v '\.cache'|grep -v MERGING|sed 's!/var/db/pkg/!!'); do
	if [[ $(php -r "echo filemtime('/var/db/pkg/$i');") < 1234567890 ]]; then
		PCKGS="${PCKGS} =${i}"
	fi
done

emerge -av1 --keep-going ${PCKGS}

где 1234567890 - это unixtime. Пакеты, старше этого времени, требуется пересобрать.

>Вот пример утилиты, собранной с 4.3.2:

А

fix_libtool_files.sh 3.4.9
fix_libtool_files.sh 4.1.2

делались?

>> Слыхал, что некоторые программы не хотят собираться с GCC 4.3.X, сталкивались ли вы с этим?

>Как пример qemu.


а вы еще не в курсе что недавно вышла новая версия, которая отлично с 4.3.x собирается ?

если даже в debian в стабильном релизе перешли на 4.3, значит можно

> >Вот пример утилиты, собранной с 4.3.2:
> А
> fix_libtool_files.sh 3.4.9
> fix_libtool_files.sh 4.1.2

Нет, а что это за скрипты?

> >Как пример qemu.
> а вы еще не в курсе что недавно вышла новая версия, которая отлично с 4.3.x собирается ?

Нет, не знал. Спасибо.

Исправляет в бинарниках ссылки на либы удалённых старых версий GCC. _Обязательны_ к запуску при удалении любой версии GCC, если ей хоть что-то компилилось.

Параметр - удалённая версия GCC.

Собственно:

# qfile fix_libtool_files.sh
sys-devel/gcc (/usr/share/gcc-data/i686-pc-linux-gnu/4.3.3/fix_libtool_files.sh)


# fix_libtool_files.sh
Usage: fix_libtool_files.sh <old-gcc-version> [--oldarch <old-CHOST>]

    Where <old-gcc-version> is the version number of the
    previous gcc version.  For example, if you updated to
    gcc-3.2.1, and you had gcc-3.2 installed, run:

      # fix_libtool_files.sh 3.2

    If you updated to gcc-3.2.3, and the old CHOST was i586-pc-linux-gnu
    but you now have CHOST as i686-pc-linux-gnu, run:

      # fix_libtool_files.sh 3.2 --oldarch i586-pc-linux-gnu

    Note that if only the CHOST and not the version changed, you can run
    it with the current version and the '--oldarch <old-CHOST>' arguments,
    and it will do the expected:

      # fix_libtool_files.sh `gcc -dumpversion` --oldarch i586-pc-linux-gnu

> Исправляет в бинарниках ссылки на либы удалённых старых версий GCC. _Обязательны_ к запуску при удалении любой версии GCC, если ей хоть что-то компилилось.

Спасибо, не знал об этом. Похоже идет с пакетом sys-devel/libtool.

Запустил на рабочем компьютере:
# fix_libtool_files.sh 4.3.2
* Scanning libtool files for hardcoded gcc library paths...
* [1/5] Scanning /lib ...
* [2/5] Scanning /usr/lib ...
* [3/5] Scanning /usr/games/lib ...
* [4/5] Scanning /usr/i686-pc-linux-gnu/lib ...
* [5/5] Scanning /usr/local/lib ...

На этом все. Так и должно быть?

p.s. Пару недель назад я сделал emerge world -e

> # qfile fix_libtool_files.sh
> sys-devel/gcc (/usr/share/gcc-data/i686-pc-linux-gnu/4.3.3/fix_libtool_files.sh)

Точно, я ошибся с пакетом. Тут оно:

# equery b fix_libtool_files.sh
[ Searching for file(s) fix_libtool_files.sh in *... ]
sys-devel/gcc-4.1.2 (/usr/share/gcc-data/i686-pc-linux-gnu/4.1.2/fix_libtool_files.sh)

Еще раз спасибо.

>На этом все. Так и должно быть?

Судя по всему, ничего, собранного с 4.3.2 он не нашёл. Иначе, ЕМНИП, он пишет отчёт о фиксах.

А у тебя точно проблема со снесённым 4.3.2, а не 4.1.2 или 3.4.9, на которые у тебя там ругается test?

Прогони:

fix_libtool_files.sh 3.4.9
fix_libtool_files.sh 4.1.2

А как правильно пересобирать систему потом? Некоторые советуют пересобрать 2 раза system, потом world, другие говорят что однократной пересборки system достаточно. Как правильно?

После обновления компилятора пересобрать linux-headers, glibc, binutils, потом один раз system и, по желанию, world.

Спасибо. Вопрос исчерпал себя, тема закрыта. Благодарность всем откликнувшимся

> После обновления компилятора пересобрать linux-headers, glibc, binutils, потом один раз system и, по желанию, world.

А зачем всё сразу пересобирать? Прирост производителности будет в 1-2%. Всё само со временем при обновлениях новым компилятором соберётся.

> Судя по всему, ничего, собранного с 4.3.2 он не нашёл. Иначе, ЕМНИП, он пишет отчёт о фиксах.

Проверил дома - ничего не нашел.

А у тебя точно проблема со снесённым 4.3.2, а не 4.1.2 или 3.4.9, на которые у тебя там ругается test?

Точно с 4.3.2. Если переключиться на gcc-4.3.2, то софт работает.

Прогони:

fix_libtool_files.sh 3.4.9
fix_libtool_files.sh 4.1.2

Аналогично.