Powered By Blogger

Tuesday, August 12, 2014

crossdev на funtoo

Ждём ебилдов


Я уже очень давно не писал о вещах насущных и приземлённых и наверно не стал бы этого делать впредь, если бы не одно происшествие. Небольшая предыстория. Просто чтобы как-то занять место. Когда-то я пользовался ubuntu, но потом перестал и перешёл на gentoo. Сей дистрибутив пришёлся мне зело по нраву. Нет, дело отнюдь не в мифических процентах производительности. Просто gentoo позволяет вертеть пакетами по своему желанию и усмотрению в довольно широких пределах. Чуть позже передо мной встал вопрос, на что заменить уже на другой системе старый, заваленный всяким хламом Debian, который было проще убить, чем пытаться дальше шаманить с обновлениями (и не зря, как убедительно показали страсти по systemd какое-то время спустя - выхаживать Debian ради того, чтобы однажды к тебе приехало вышеупомянутое чудо поттерингомысли...) Кое-кто из знакомых пользовался форком gentoo - funtoo, ну и не то мне посоветовали попробовать, не то самому стало интересно, в общем, я решился на эксперимент. Тем более, что это практически та же gentoo, только в профиль и с git'ом вместо rsync'а для обновлений, никаких проблем возникнуть не должно было. Так в целом и получилось. Дела шли неплохо, пока однажды я подумал, а не поставить ли мне mingw-w64 там, как и на gentoo? Всё удобнее, чем всякую мелочь при необходимости собирать на соседнем хосте. Вытянул я требуемый для сего crossdev, повелеваю системе

crossdev -S -t i686-w64-mingw32
И продолжаю заниматься своими делами, благо не близкий свет - пока всё соберётся. Что поделаешь, плата за гибкость.

И тут началось... Дело в том, что crossdev берёт на себя весь труд утащить из интернетов всё, что нужно и расквартировать это у вас на диске. Всё, что нужно, включает binutils, mingw64-runtime конкретно для таргета i686-w64-mingw32, собственно gcc. binutils собирается без проблем, gcc тоже... Кажется. mingw64-runtime стоит колом, хоть ты тресни. Давайте разбираться. По умолчанию crossdev приволочёт вам последний стабильный ебилд, в моём случае, это был gcc-4.8.2, в то время, как хост пользуется gcc-4.7.3, 4.8 для хоста я замаскировал. Честно признаться, не вдаваясь особо в детали, я сначала подумал было, что косяк с версией. На gentoo последний ебилд из серии >4.8.2 категорически не собирается под i686-w64-mingw32, мотивируя этом неразрешёнными символами. Ну что ж, я вполне счастлив и с 4.8.2. Там я просто замаскировал до поры до времени то, что не собирается, просто чтобы не тратить время на пустые попытки и не стопорить прочие обновления. Здесь решил поступить так же, с той лишь разницей, что под маской должны были скрыться все компиляторы >4.8, т.о., ко мне должен был приехать компилятор той же версии, что у хоста - 4.7.3-r2. В общем, командую:

crossdev -S -t i686-w64-mingw32 --g 4.7.3-r2
и дальше по своим делам.

Итог - file collision. То, что должно быть установлено этим ебилдом, каким-то образом уже есть в системе. Забавная петрушка. Но и правда, emerge пытается скопировать файлы с именем i686-pc-linux-*-4.7.3, при том, что такие файлы уже есть в /usr и совершенно внезапно принадлежат они моему законному хост-компилятору. Коллизия вполне очевидная. И что ещё смешнее, будь это уже упомянутый gcc-4.8.2, у вас и окажется i686-pc-linux-*-4.8.2! А вот i686-w64-mingw32-*-4.8.2 вы ни в жисть не увидите. И в этом вы будете не одиноки. Скрипт конфигурирования mingw64-runtime тоже его не увидит, потому что его нет.

Улавливаете логику? Ваш crossdev становится лазейкой для контрабанды замаскированных версий gcc! Вместо того, чтобы собрать и поставить в систему компилятор под таргет i686-w64-mingw32, он соберёт вам ещё один компилятор для того же таргета, что и ваш хост (CHOST = CTARGET, unconditionally) и поставит его рядом, не забыв сделать компилятором по умолчанию. Вот это проливает свет на причину. А вот здесь немножко обсуждения, самхау рилейтед. Похоже, местный Патрегбох нещадно поломал ебилды компиляторов. Вот, собственно, и всё недолга. Все мы люди - хотелось как лучше, а получилось не очень. Фикс есть, хотя достаточно костыльный, но действенный. Можно утащить ебилд gcc из gentoo, иных путей, кроме тотального переписывания ебилда или отката коммитов я лично не увидел. Но первое слишком муторно, а второе уже не в нашей власти, если говорить о глобальных изменениях. Хотя crossdev собирает инструментарий для кросскомпиляции в оверлее, есть одна хитрость, ебилды он берёт системные, что почему-то особого удивления и не вызывает, так что можно утащить ебилд откуда-нибудь отсюда или из /usr/portage/sys-devel/gcc на работающей gentoo-системе и кинуть его в аналогичное место на funtoo. Есть подводный камень, если ебилд, устанавливаемый crossdev'ом имеет ту же версию, что ваш хост-компилятор. С вероятностью, равной единице, ваш хост-компилятор очень захочет пересобраться при следующей проверке обновлений системы (emerge -uDNpv world) из-за разницы в флагах. Поэтому стратегически выгоднее ставить версию компилятора где-то рядом с вашей, а не такую же. Например, если у вас хост-компилятор gcc-4.7.3-r2, то попросите crossdev поставить gcc-4.7.3-r1. Топорный путь, но что поделаешь. Зато быстрый и работает. В общем, ждём-с.

ПОСЕТИТЕЛИ

free counters