Сборка ебилда, который требует самого себя для сборки

Я не пинкбайт, но я лично не вижу смысла в отдельном ебилде для fasm-source. Гораздо логичнее здесь просто бинарь.

это ж не Ъ, вдруг аффтар туда закладок запихнул :)

gcc, внезапно, тоже сам себя собирает

ммм... А что тебе мешает в процессе сборки (шаг 1) скачать бинарь и собрать им исходники, потом (шаг 2) собрать те же исходники тем, что получилось на (шаг 1), ну и опционально шаг 3.

Т.е. зачем тебе ещё один ненужный -bin пакет?

Но gcc в base system, в отличие от fasm.

ну это черезжопинг и костылинг.

ну это черезжопинг и костылинг.

не совсем, половина пакетов таким страдает
потому и реализован механизм типо «override»
для примера предположительно большой ебилд:

$ cat /home/portage/www-client/firefox/firefox-24.8.0.ebuild | grep -e  configure\(\) -e inst\(\)
src_configure() {
pkg_preinst() {
pkg_postinst() {

обычные сырци при этом собираются ебилдом ограничивающимся указанием SRC

gcc, внезапно, тоже сам себя собирает

Просто первичный компилятор есть в системе изначально.

Обнаружил как-то, что в дереве portage нету ассемблера fasm.

В портаже нет, в оверлеях есть: dev-lang/fasm.

Так что ничего писать не нужно.

таки оно бинарную сборку скачивает

gcc, внезапно, тоже сам себя собирает

Только ставится в stage1 бинарником.

это ж не Ъ, вдруг аффтар туда закладок запихнул :)

Если с умом, а не абы как, написал закладки, то пересборка не поможет. Хоть стопятьсот раз.

для ассемблера, написанного на ассемблере, проверить на закладки проще как-то :)

Построчно сравниваешь дамп дизассемблера с исходниками и при обнаружении лишних инструкций поднимаешь тревогу

раскрутка

Ну да, SBCL так и собирается. В архиве с исходниками лежит бинарь, которым собирается новый бинарь, которым затем собирается еще один бинарь.

dev-lang/ghc: USE=bootstrap. Можно из бинаря собирать, можно из того, что в PATH.

Через некоторое время пришла в голову мысль, а как для него можно написать ебилд, если он написан на себе самом и соответственно требует себя для сборки?

Такого не должно быть. Пардон за виндовозничество, но это то же самое, как и знаменитый кейс c:\install\unzip.zip.

Подойди к вопросу по-другому: забудь что есть ebuild'ы - как ты ручками такое будешь собирать? Скорее по-другому: как создатели fasm расчитывают он будет собираться на какой-то lfs?

gcc - исключение, так как он есть в stage*.

Моя рекомендация - либо позволить его собирать не fasm (а какой там еще есть) если это возможно, либо, да, сделать зависимость от бинаря. Но, скорее всего, есть другой путь, который описан где-то в INSTALL или на сайте fasm.

Но, скорее всего, есть другой путь, который описан где-то в INSTALL или на сайте fasm.

не, нету

Моя рекомендация - либо позволить его собирать не fasm (а какой там еще есть)

там свой особый синтаксис

внезапно, gcc написан на с, и может быть собран не только собой

внезапно, gcc написан на с, и может быть собран не только собой

внезапно, разговор про ебилд, и гцц приведен как пример

Тогда проще не собирать, а только сделать проверку.

С другой стороны, дизассемлирование более-менее сопадает с исходником, если оный одним файлом. А если куча файлов исходников, потом линковка?

Там нет минимального компилятора?

А как его собирали разрабы О_о, если для сборки этого ассемблера нужен он же?

Старой версией, как же еще. А самая первая версия была написана на чем-нить другом.

Построчно сравниваешь дамп дизассемблера с исходниками и при обнаружении лишних инструкций поднимаешь тревогу

Ну попробуй сделать это с FASM'ом, посмотрим, как у тебя получится.

gcc написан на с++, но это не аргумент. Ядро линукса таки написанно на С, но собирается нормально только через gcc

Как в общем случае по Ъ-гентушному должны разруливаться такие ситуации?

Посмотри как это сделано в ghc - компиляторе Haskell, написанным на Haskell. ЕМНИП он бутстрапится, скачивая бинарную сборку самого себя с офсайта.

опередил :-)

В расте тоже бутстрап. И в ерланге.

внезапно, gcc написан на с, и может быть собран не только собой

Внезапно, gcc написан на c с гнутыми расширениями, некоторые из которых никто больше не умеет.

Ядро линукса таки написанно на С, но собирается нормально только

уже же собирается с clang

с гнутыми расширениями, некоторые из которых никто больше не умеет

говноедство какое-то

уже же собирается с clang

После того как они допилили совместимость с gcc. Это не есть что-то плохое в тех случаях, где требуется руками указать alignment / address space / etc. Просто в стандарте C этих вещей нет.