[devel] re-writing GNU C; part1.4.1: .rpm produced
Ivan Zakharyaschev
imz на altlinux.org
Ср Фев 17 11:19:24 MSK 2016
On Tue, 16 Feb 2016, Ivan Zakharyaschev wrote:
> Чтобы поскорее иметь возможность подсовывать cuglify/Process в hasher, стал
> делать .rpm (дурацким временным способом).
Я думал ставить в hasher специальный пакет, чтобы заставлять при сборке
использовать нечто другое вместо gcc (например, cuglify/Process, clang --
в общем, есть варианты, на чём проверить).
(Решил пока всё же в первую очередь доделкой фич в cuglify/Process
заняться. Поэтому записываю соображения про подмену gcc в hasher, чтобы
не забыть/было что пока обсудить.)
При этом пакеты хотят для сборки gcc (иногда -- явно заданной версии).
Так пусть эти gcc ставятся.
Что-то похожее по смыслу происходит при использовании ccache и distcc:
стоит настоящий gcc, но вызовы gcc обрабатываются сначала этими
прослойками. (Между прочим, если пробовать это с clang, то gcc тоже
должен стоять, потому что, как известно, он ему нужен по зависимости.)
Вообще, вокруг gcc есть механизм alternatives для выбора варианта (и
/usr/sbin/select-gcc , который ими манипулирует).
Когда вчера рассуждал вслух в разговоре с mike@ о том, какая есть практика
использования, к примеру, ccache вместо просто gcc в hasher, говорил, что
странно, что не видно задокументированного надёжного прямолинейного
способа сделать такую подмену, а, кажется, есть только какие-то
rpm-макросы, которые по моему предположению меняли вызовы CC (если они
соответствующе оформлены).
Вчера я почему-то упустил из виду, что gcc и cpp и компания у нас --
символические ссылки, ведущие на gcc_wrapper (а не альтернативы,
предосталяемые разными gccN.M). Так что всё под контролем gcc_wrapper. А
ведь я давно об этом знал.
$ readlink -f /usr/bin/gcc
/usr/bin/gcc_wrapper
$ readlink -f /usr/bin/cpp
/usr/bin/gcc_wrapper
$ rpm -q cpp5 -l | fgrep alter
/etc/alternatives/packages.d/cpp5
$ cat /etc/alternatives/packages.d/cpp5
/usr/bin/x86_64-alt-linux-cpp /usr/bin/x86_64-alt-linux-cpp-5 511
/usr/share/man/man1/cpp.1.bz2 /usr/share/man/man1/cpp-5.1.bz2 /usr/bin/x86_64-alt-linux-cpp-5
$
Меня, навреное, вчера сбило то, что /usr/bin/gcc всё-таки тоже управляется
альтернативами, и сейчас используемая альтернатива для него (gcc_wrapper)
предоставляется пакетом gcc-common:
$ l /usr/bin/gcc
lrwxrwxrwx 1 root root 36 дек 29 2014 /usr/bin/gcc -> /etc/alternatives/links/|usr|bin|gcc
$
Не знаю, есть ли в Сизифе другие пакеты, которые другую альтернативу для
него дают.
(BTW, не смог найти команду, которая бы показывала бы, какие есть
установленные в системе альтернативы для определённого пути. Например:
хочу знать, какие есть альтернативы для /usr/bin/x86_64-alt-linux-gcc .
Только grep-ать /etc/alternatives/?)
Какой-нибудь пакет dummy-gcc-clang или dummy-gcc-cuglify, который мы будем
просить hasher установить в сборочную среду, мог бы как раз предоставлять
альтернативу для /usr/bin/gcc (и /usr/bin/cpp) с очень большим
приоритетом. Или задействовать существующий gcc_wrapper для того, что
нам хочется (если в нём такое предусмотрено; и ещё бы как-нибудь
запретить её переключать, если в gcc_wrapper есть такая возможность).
И можно было бы передвигать другие пути к GCC вроде /usr/bin/gcc-5 или
/usr/bin/*-gcc , чтобы гарантировать, что к ним напрямую не обращаются во
время сборки. (Напимер, файл-триггером, потому что я не уверен, что в
hasher есть hook для выполнения команды после установки сборочной среды.)
--
Best regards,
Ivan
Подробная информация о списке рассылки Devel