Как собрать gcc со своими ключами в gentoo?

запилить свой екласс?
ебыдло gcc использует екласс toolchain, который в свою очередь использует flag-o-matic
а вот он то и чудит:
strip-flags
replace-flags -O? -O2
strip-unsupported-flags
filter-flags '-mabi*' -m31 -m32 -m64
replace-cpu-flags k8 athlon64 opteron i686 x86-64
replace-cpu-flags pentium-m pentium3m pentium3
filter-flags '-mtune=*'
replace-cpu-flags core2 nocona
replace-cpu-flags core2 prescott
filter-flags -f{no-,}unit-at-a-time -f{no-,}web -mno-tls-direct-seg-refs
filter-flags -f{no-,}stack-protector{,-all}
filter-flags -fvisibility-inlines-hidden -fvisibility=hidden
и т.д. и т.п.
короче - гемор
а нахрена тебе это вообще?

Не очень ясно, что мешает решить проблему средствами make, т.е. либо определить .c.o, заменить CC на gcc $CFLAGS и т.п.?

Или таки есть жедание чтобы gcc всегда подхватывал CFLAGS? Или всегда использовал определенные опции оптимизации? В принципе хотя spec-файл и отсутствует никто не мешает его написать и использовать по умолчанию.

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

Я не так крут как кажется;)

В принципе мне хватило бы подхвата CFLAGS и CXXFLAGS из make.conf, но могу потрудится и смастерить spec-файл. Если делать spec-файл, то у меня возникают вопросы, т.к. ранее я с этим не сталкивался ни разу:

1.Он должен прописывать все параметры gcc или только ту часть, которую нужно подменить. 2.Куда прописать запуск параметра specs? В /etc/portage/..., назначив gcc этот параметр отдельно? 3.Я вообще правильно все понял или мягко выражаясь потерялся?

Если есть желание развлечься, то вперед (правда у меня 4.4.x), но
принцип думаю не поменялся:

1. Получаем информацию о директории инсталяции:
gcc -print-search-dirs
install: /usr/lib/gcc/i686-redhat-linux/4.4.5/
...

2. Сохраняем в нее default spec файл (нужны права):
# gcc -dumpspecs > /usr/lib/gcc/i686-redhat-linux/4.4.5/specs
Можно и в другое место, но тогда потребуется -specs ключ.

3. Проверяем что файл подхватывается по умолчанию:
gcc -v
Reading specs from /usr/lib/gcc/i686-redhat-linux/4.4.5/specs <<<<<
Target: i686-redhat-linux

До появления файла вывод был:
gcc -v
Using built-in specs.
Target: i686-redhat-linux

4. Находим в новом файле фрагмент *cc1_options: и аккуратно
его правим. Например для начала добавляем -O0 или -O3
(добавим оба) по умолчанию. Проверим поведение:
gcc -v -c tmp.c
.....
/usr/libexec/gcc/i686-redhat-linux/4.4.5/cc1 -quiet -v tmp.c -quiet -dumpbase tmp.c -mtune=generic -march=i686 -auxbase tmp -version -O0 -O3 -o /tmp/cctYskOL.s
.....
5. Переименовываем/удаляем файл после экспериментов, дабы не мешал.
mv /usr/lib/gcc/i686-redhat-linux/4.4.5/specs{,.tmp}
gcc -v
Using built-in specs.
Target: i686-redhat-linux

Спасибо! Я и не рассчитывал, что будет так подробно. Благодарю.

Если иcключить спец. эксперименты, то через make логичнее,
может даже сработать такое:

export CC=«gcc -O0 -O3»
$ make tmp.o
gcc -O0 -O3 -c -o tmp.o tmp.c
$ unset CC; rm tmp.o; make tmp.o
cc -c -o tmp.o tmp.c

Заметим компилятор тоже «разный».
В Makefile CC не упоминается - все по умолчанию.

А почему gcc должен читать make.conf ?

На сборку самого gcc новый spec не повлиял никак. Он упорно подставляет свои внутренние параметры компиляции.

Изначальная задача перекомпилировать сам gcc 4.5.3-r1 с новыми параметрами.

«Собери GCC с -O3 и получи много разнообразного секса»?

Какая разница с чем я буду собирать gcc? Я тестирую на своей личной машине. Какие ко мне могут быть претензии?!

P.S.

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

Просил помощи в реализации смены ключей для сборки пакета gcc, а не в, простите, дурацких комментариях. Вам результаты не интересны, а мне интересны и есть немного моего личного времени для попытки. Возможно есть и другие люди, кроме меня, кому были бы интересны результаты.

У как далеко завело ...

gcc на определенной стадии компиляируется самим новым boot gcc, а тому никто spec-файл не менял, т.ч. поведение корректное.

When GCC is configured for a native configuration, the default action for `make' is to do a full three-stage bootstrap. This means that GCC is built three times--once with the native compiler, once with the native-built compiler it just built, and once with the compiler it built the second time. In theory, the last two should produce the same results, which `make compare' can check. Each stage is configured separately and compiled into a separate directory, to minimize problems due to ABI incompatibilities between the native compiler and GCC.

См. «info gccint». При сборке gcc можно использовать различные CFLAGS переменные. Например (сам раньше использовал другие):

If you wish to use non-default GCC flags when compiling the stage2 and stage3 compilers, set `BOOT_CFLAGS' on the command line when doing `make'.

`SPECS' Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since it does not affect the build of target libraries, at least not the build of the default multilib. One possible work-around is to use `DRIVER_SELF_SPECS' to bring options from the `specs' file as if they had been passed in the compiler driver command line. However, you don't want to be adding these options after the toolchain is installed, so you can instead tweak the `specs' file that will be used during the toolchain build, while you still install the original, built-in `specs'. The trick is to set `SPECS' to some other filename (say `specs.install'), that will then be created out of the built-in specs, and introduce a `Makefile' rule to generate the `specs' file that's going to be used at build time out of your `specs.install'.

`T_CFLAGS' These are extra flags to pass to the C compiler. They are used both when building GCC, and when compiling things with the just-built GCC. This variable is deprecated and should not be used.

Слов нет. Огромное спасибо. Блин где бы подучится мне, чтобы не мучить всех дурацкими вопросами... Очень неудобно спрашивать, а приходится, так как порою не знаю в каком направлении искать даже(

P.S. Если чем могу быть полезен, я к Вашим услугам.

В моем случае достаточно прописать в make.conf два параметра:

BOOT_CFLAGS="${CFLAGS}"
T_CFLAGS="${CFLAGS}"

Еще раз благодарю. Запустил gcc на сборку. Результаты напишу.

P.S.

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

Оставил из аналогичных соображений :-)

Опции «ползут» постоянно.