strace нерабочего кросс-компилятора:

$ strace -f -e execve aarch64-linux-gnu-gcc -c -x assembler -o test.o test.S

execve("/usr/bin/aarch64-linux-gnu-gcc", ["aarch64-linux-gnu-gcc", "-c", "-x", "assembler", "-o", "test.o", "test.S"], 0x7ffc7b2c6c88 /* 30 vars */) = 0
strace: Process 12533 attached
[pid 12533] execve("/home/asheplyakov/bin/as", ["as", "-EL", "-mabi=lp64", "-o", "test.o", "test.S"], 0xd8a9b0 /* 32 vars */) = -1 ENOENT (No such file or directory)
[pid 12533] execve("/home/asheplyakov/bin/as", ["as", "-EL", "-mabi=lp64", "-o", "test.o", "test.S"], 0xd8a9b0 /* 32 vars */) = -1 ENOENT (No such file or directory)
[pid 12533] execve("/sbin/as", ["as", "-EL", "-mabi=lp64", "-o", "test.o", "test.S"], 0xd8a9b0 /* 32 vars */) = -1 ENOENT (No such file or directory)
[pid 12533] execve("/usr/sbin/as", ["as", "-EL", "-mabi=lp64", "-o", "test.o", "test.S"], 0xd8a9b0 /* 32 vars */) = -1 ENOENT (No such file or directory)
[pid 12533] execve("/usr/local/sbin/as", ["as", "-EL", "-mabi=lp64", "-o", "test.o", "test.S"], 0xd8a9b0 /* 32 vars */) = -1 ENOENT (No such file or directory)
[pid 12533] execve("/bin/as", ["as", "-EL", "-mabi=lp64", "-o", "test.o", "test.S"], 0xd8a9b0 /* 32 vars */) = -1 ENOENT (No such file or directory)
[pid 12533] execve("/usr/bin/as", ["as", "-EL", "-mabi=lp64", "-o", "test.o", "test.S"], 0xd8a9b0 /* 32 vars */) = 0
as: unrecognized option '-EL'
[pid 12533] +++ exited with 1 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=12533, si_uid=1000, si_status=1, si_utime=0, si_stime=0} ---
+++ exited with 1 +++

strace здорового кросс-компилятора (Debian):

strace -f -e execve aarch64-linux-gnu-gcc -c -x assembler -o test.o test.S

execve("/usr/bin/aarch64-linux-gnu-gcc", ["aarch64-linux-gnu-gcc", "-c", "-x", "assembler", "-o", "test.o", "test.S"], 0x7ffc701ad968 /* 62 vars */) = 0
strace: Process 25682 attached
[pid 25682] execve("/usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/as", ["/usr/lib/gcc-cross/aarch64-linux"..., "-EL", "-mabi=lp64", "-o", "test.o", "test.S"], 0x13a14d0 /* 64 vars */) = 0
[pid 25682] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=25682, si_uid=1000, si_status=0, si_utime=0, si_stime=2} ---
+++ exited with 0 +++

Created attachment 9000 [details]
Полный strace нерабочего кросс-компилятора

Created attachment 9001 [details]
Полный strace кросс-компилятора здорового человека

gcc пытается найти ассемблер по пути /usr/aarch64-linux-gnu/bin/as, а его там нет. От полной безнадеги gcc пробует /usr/bin/as, но толку, конечно, никакого.
Наверное нужно научить cross-binutils устанавливать симлинки (на as, ld, и прочие) в /usr/$target/bin

> Наверное нужно научить cross-binutils устанавливать симлинки (на as, ld, и прочие) в /usr/$target/bin

Попытался, и получил

sisyphus_check: check-fhs ERROR: FHS violation
/.out/binutils-arm-linux-gnu-2.31.1-alt1_2.aarch64.rpm: FHS violations: /usr/arm-linux-gnu /usr/arm-linux-gnu/sys-root /usr/arm-linux-gnueabi /usr/arm-linux-gnueabi/bin /usr/arm-linux-gnueabi/bin/ar /usr/arm-linux-gnueabi/bin/as /usr/arm-linux-gnueabi/bin/ld /usr/arm-linux-gnueabi/bin/ld.bfd /usr/arm-linux-gnueabi/bin/nm /usr/arm-linux-gnueabi/bin/objcopy /usr/arm-linux-gnueabi/bin/objdump /usr/arm-linux-gnueabi/bin/ranlib /usr/arm-linux-gnueabi/bin/readelf /usr/arm-linux-gnueabi/bin/strip

Еще один случай, когда от FHS больше вреда, чем пользы.

В инструкции по сборке GCC https://gcc.gnu.org/install/build.html, в параграфе "Building a cross compiler" четко написано:

If you are not building GNU binutils in the same source tree as GCC, you will need
a cross-assembler and cross-linker installed before configuring GCC. 
Put them in the directory prefix/target/bin.

Here is a table of the tools you should put in this directory:

as

    This should be the cross-assembler.
ld

    This should be the cross-linker.
ar

    This should be the cross-archiver: a program which can manipulate archive files (linker libraries) in the target machine’s format.

ranlib

    This should be a program to construct a symbol table in an archive file. 

The installation of GCC will find these programs in that directory, and copy or link them to the proper place to for the cross-compiler to find them when run later.

Так что в данном случае FHS придется немного потесниться.

(Ответ для Alexey Sheplyakov на комментарий #6)
> В инструкции по сборке GCC https://gcc.gnu.org/install/build.html, в
> параграфе "Building a cross compiler" четко написано:
> 
> If you are not building GNU binutils in the same source tree as GCC, you
> will need
> a cross-assembler and cross-linker installed before configuring GCC. 
> Put them in the directory prefix/target/bin.

К счастью, это настраивается.

> Так что в данном случае FHS придется немного потесниться.

Не придётся, при сборке gcc достаточно выставить правильное значение переменной tooldir.

> при сборке gcc достаточно выставить правильное значение переменной tooldir.

$ wget -q http://mirror.tochlab.net/pub/gnu/gcc/gcc-7.5.0/gcc-7.5.0.tar.xz
$ tar xaf gcc-7.5.0.tar.xz
$ cd gcc-7.5.0
$ ./configure --target=aarch64-linux-gnu --prefix=/usr --tooldir=/usr/lib/aarch64-linux-gnu
configure: error: unrecognized option: `--tooldir=/usr/lib'
Try `./configure --help' for more information.

$ ./configure --help | grep tool
  --with-build-time-tools=PATH
                          use given path to find target tools during the build


> К счастью, это настраивается.

Из документации (https://gcc.gnu.org/install/configure.html) и фактического поведения configure скрипта следует строго обратный вывод.

Я думаю, что здесь имеет смысл добавить исключение в sisyphus-check, причём не столько чтобы упростить жизнь мейнтейнерам cross-*, сколько для того, чтобы сделать "как все":
- у нас уже есть avr-binutils, складывающий своё всё в /usr/avr/
- в других дистрибутивах кроссовые binutils запакованы в /usr/<триплет>/bin -- вот тут например есть списки файлов мз пакетов Fedora и Debian:

https://fedora.pkgs.org/33/fedora-x86_64/binutils-aarch64-linux-gnu-2.35.1-1.fc33.x86_64.rpm.html
https://debian.pkgs.org/11/debian-main-amd64/binutils-aarch64-linux-gnu_2.35.1-2_amd64.deb.html

(Ответ для Alexey Sheplyakov на комментарий #8)
> > при сборке gcc достаточно выставить правильное значение переменной tooldir.
> 
> $ wget -q http://mirror.tochlab.net/pub/gnu/gcc/gcc-7.5.0/gcc-7.5.0.tar.xz
> $ tar xaf gcc-7.5.0.tar.xz
> $ cd gcc-7.5.0
> $ ./configure --target=aarch64-linux-gnu --prefix=/usr
> --tooldir=/usr/lib/aarch64-linux-gnu
> configure: error: unrecognized option: `--tooldir=/usr/lib'

Я не ожидал, что вы решите, что это параметр configure.  Особенно, если учесть, что в cross-gcc.spec переменная tooldir явно передаётся через make и имеет там достаточно странное значение.

(In reply to Ivan A. Melnikov from comment #9)
> Я думаю, что здесь имеет смысл добавить исключение в sisyphus-check, причём
> не столько чтобы упростить жизнь мейнтейнерам cross-*, сколько для того,
> чтобы сделать "как все":
> - у нас уже есть avr-binutils, складывающий своё всё в /usr/avr/

Я полагаю, что это было ошибочным решением, подлежащим пересмотру.

> Я полагаю, что это было ошибочным решением, подлежащим пересмотру.

Ошибочным решением было (и есть, и будет)

1) сломать то, что работает, лишь бы sisyphus_check не отсвечивал
2) сделать лишь бы не как у всех

(In reply to Alexey Sheplyakov from comment #12)
> > Я полагаю, что это было ошибочным решением, подлежащим пересмотру.
> 
> Ошибочным решением было (и есть, и будет)
> 
> 1) сломать то, что работает, лишь бы sisyphus_check не отсвечивал
> 2) сделать лишь бы не как у всех

У всех суидный passwd, давайте сделаем у нас так же, как у всех.
Вот и сейчас техническая экспертиза подменяется желанием сделать "как у всех".
Я такое уже слышал не раз, большое спасибо.

(In reply to Gleb F-Malinovskiy from comment #7)
[...]
> Не придётся, при сборке gcc достаточно выставить правильное значение
> переменной tooldir.

Это другой tooldir -- префикс для каталога gcc/<machine>/<version>, в который GCC кладёт свои исполняемые части (cc1, lto-wrapper и прочее, а также библиотеки). Более того, в главном Makefile'е gcc (том, который получается из Makefile.in) оно жестко переопределяется в то, которое задал configure, и возможность задать что-то другое не предусмотренна ни при вызове configure, ни при вызове make. И это хорошо.

Пареметр tooldir=... у make похоже просто игнорируется и его наличие -- такая мелкая ошибка, которая запутывает, но ни на что не влияет.

Теперь о том, что же нам делать. Сейчас aarch64-linux-gnu-gcc ищет as по следующим путям:

"/usr/lib/gcc/aarch64-linux-gnu/8/as"
"/usr/lib/gcc/aarch64-linux-gnu/as"
"/usr/lib/gcc/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/aarch64-linux-gnu/8/as"
"/usr/lib/gcc/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/as"

Эти пути получаются добавлением различных суффиксов ("aarch64-linux-gnu", "8") к префиксам из exec_prefixes из gcc.c. В этот список попадают
- аргументы опции -B
- содержимое переменной среды COMPILER_PATH, если она есть (по умолчанию её нет, сам же драйвер её выставляет для тех процессов, которые создаёт)
- несколько внутренних путей gcc, которые в нашем случае все равны /usr/lib/gcc
- некая адовая конструкция, которая резолвится в %_prefix/<spec_machine>/bin (см. [1] на происходящее с tooldir_prefix{,2})

[1] http://git.altlinux.org/srpms/c/cross-gcc.git?p=cross-gcc.git;a=blob;f=gcc/gcc/gcc.c;h=a716f7082591d105c69f6970eb7856671b15c319;hb=d8b4b2178068eec9aa6ace71591f3a5bca40de82#l4574

Так что на первый (но очень внимательный) взгляд *это*, к сожалению, не настраивается, и требуется патчить gcc чтобы заставить его искать binutil'ы по какому-то другому, ALT-специфичному пути.

While we are at it, /usr/lib/<триплет> тоже как-то криво смотрится, я бы переложил куда-нибудь и его, и sys-root. Раз уж мы патчим всё. Мнения?

(In reply to Dmitry V. Levin from comment #13)
> (In reply to Alexey Sheplyakov from comment #12)
> > > Я полагаю, что это было ошибочным решением, подлежащим пересмотру.
> > 
> > Ошибочным решением было (и есть, и будет)
> > 
> > 1) сломать то, что работает, лишь бы sisyphus_check не отсвечивал
> > 2) сделать лишь бы не как у всех
> 
> У всех суидный passwd, давайте сделаем у нас так же, как у всех.
> Вот и сейчас техническая экспертиза подменяется желанием сделать "как у всех".
> Я такое уже слышал не раз, большое спасибо.

Уход от общепринятой практики создаёт проблемы как мейнтейнерам, так и пользователям, а значет должен что-то приносить взамен. Вот например, можно показать, что несуидный passwd безопаснее суидного. А что принесёт перенос cross-binutils в дистрибутивоспецифичное место? Ссылки на *стандарт* (FHS) в качестве обоснования выглядят немного иронично.

Дима, Глеб, что предлагаете? 
 Одобрит ли апстрим такой патч gcc?

(In reply to AEN from comment #16)
> Дима, Глеб, что предлагаете? 
>  Одобрит ли апстрим такой патч gcc?

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

(Ответ для Dmitry V. Levin на комментарий #17)
> (In reply to AEN from comment #16)
> > Дима, Глеб, что предлагаете? 
> >  Одобрит ли апстрим такой патч gcc?
> 
> Пакет cross-gcc цельнотянутый из Федоры, так что, грубо говоря, все вопросы
> по нему туда.
> У нас в альте есть задача сделать нормальный альтовый cross-gcc, но она
> относительно сложная и низкоприоритетная.


Проблема в том, что он нужен, особенно учитывая проблему с loongson, которые китайские товарищи решили не выпускать из Поднебесной по примеру Эльбрусов.  А потому приоритет задачи серьезно вырос. Потому вопрос о том, можно ли и как сделать приемлемый для апстрима патч gcc актуален и я прошу совета у Вас и у Глеба.
А нельзя ли собрать кросс-тулчейн в /opt ? Вроде, это не противоречит FHS.

(In reply to AEN from comment #18)
> (Ответ для Dmitry V. Levin на комментарий #17)
> > (In reply to AEN from comment #16)
> > > Дима, Глеб, что предлагаете? 
> > >  Одобрит ли апстрим такой патч gcc?
> > 
> > Пакет cross-gcc цельнотянутый из Федоры, так что, грубо говоря, все вопросы
> > по нему туда.
> > У нас в альте есть задача сделать нормальный альтовый cross-gcc, но она
> > относительно сложная и низкоприоритетная.
> 
> Проблема в том, что он нужен, особенно учитывая проблему с loongson, которые
> китайские товарищи решили не выпускать из Поднебесной по примеру Эльбрусов. 
> А потому приоритет задачи серьезно вырос. Потому вопрос о том, можно ли и
> как сделать приемлемый для апстрима патч gcc актуален и я прошу совета у Вас
> и у Глеба.
> А нельзя ли собрать кросс-тулчейн в /opt ? Вроде, это не противоречит FHS.

Я предлагаю сперва найти мантейнера пакету, а потом, если ему понадобится совет, он сам спросит.

Здавствуйте, я потенциальный мейнтейнер инструментов для кросс-компиляции в Сизифе. Нашёлся сам ещё около пяти комментариев назад, по собственной инициативе.

Хочу сразу отметить, что моя позиция по обсуждаемому вопросу не изменилась: да, /usr/<triplet> это ужас, но принять этот ужас -- меньшее зло, чем создавать ещё одну несовместимость ALT со всеми вообще на этом до недавнего времени пустом месте. Возможно, это делает меня неподходящим человеком для поддержки инструментария для кросс-компиляции и aen@ нужно искать кого-то на эту роль.

Несмотря на сказанное выше я готов подойти с технической и прагматической точки стороны и подготовить патч к gcc, который сделает путь к binutils настраевыемым,  аналогично sys-root -- то есть, добавит ту функциональность, которую Глеб выше предполагал, а я не нашёл.

Но здесь мне нужен совет по двум вопросам.

(1) Как обосновать необходимость такого патча апстриму gcc?
(2) Куда лучше положить <triplet>/bin и <triplet>/sys-root вместо /usr? Вариант /usr/lib/<triplet>  (который в cross-binutils) сейчас кажется мне не намного лучше. /usr/libexec/<triplet>?

Дмитрий, Глеб, выскажитесь пожалуйста.

(In reply to Ivan A. Melnikov from comment #14)
> Теперь о том, что же нам делать. Сейчас aarch64-linux-gnu-gcc ищет as по
> следующим путям:
> 
> "/usr/lib/gcc/aarch64-linux-gnu/8/as"

А почему у нас в этом месте нет симлинка на тот as, который нужен?

(In reply to Dmitry V. Levin from comment #21)
> (In reply to Ivan A. Melnikov from comment #14)
> > Теперь о том, что же нам делать. Сейчас aarch64-linux-gnu-gcc ищет as по
> > следующим путям:
> > 
> > "/usr/lib/gcc/aarch64-linux-gnu/8/as"
> 
> А почему у нас в этом месте нет симлинка на тот as, который нужен?


1) /usr/lib/gcc/aarch64-linux-gnu/8 предназначена для компонент собственно gcc (cc1plus, collect2, и вот это все)
2) Тогда cross-binutils должен будет как-то узнать, какие возможны версии gcc

(In reply to Alexey Sheplyakov from comment #22)
> (In reply to Dmitry V. Levin from comment #21)
> > (In reply to Ivan A. Melnikov from comment #14)
> > > Теперь о том, что же нам делать. Сейчас aarch64-linux-gnu-gcc ищет as по
> > > следующим путям:
> > > 
> > > "/usr/lib/gcc/aarch64-linux-gnu/8/as"
> > 
> > А почему у нас в этом месте нет симлинка на тот as, который нужен?
> 
> 
> 1) /usr/lib/gcc/aarch64-linux-gnu/8 предназначена для компонент собственно
> gcc (cc1plus, collect2, и вот это все)

Если gcc начинает поиск с /usr/lib/gcc/aarch64-linux-gnu/8/as, значит, это вполне подходящее место для того, чтобы этот файл существовал.

> 2) Тогда cross-binutils должен будет как-то узнать, какие возможны версии gcc

Зачем?  Если паковать /usr/lib/gcc/aarch64-linux-gnu/8/as, то в составе cross-gcc, поскольку им будет эксклюзивно пользоваться cross-gcc.

Заодно и автоматическая зависимость на cross-binutils появится.

> > 1) /usr/lib/gcc/aarch64-linux-gnu/8 предназначена для компонент собственно
> > gcc (cc1plus, collect2, и вот это все)
> 
> Если gcc начинает поиск с /usr/lib/gcc/aarch64-linux-gnu/8/as, значит, это
> вполне подходящее место для того, чтобы этот файл существовал.

Нет. Это значит, что на тех ОС, где системным ассемблером пользоваться не выходит (Solaris, например), в этом месте gcc ожидает найти GNU as

> > 2) Тогда cross-binutils должен будет как-то узнать, какие возможны версии gcc
> 
> Зачем?  Если паковать /usr/lib/gcc/aarch64-linux-gnu/8/as, то в составе
> cross-gcc, поскольку им будет эксклюзивно пользоваться cross-gcc.

1) Предположение неверное. Ассемблером пользуются, например, люди, которые пишут оптимизированные реализации прямо на ассемблере. (И да, эти люди тоже ожидают найти ассемблер в /usr/$target/bin)
2) Вполне возможно (и даже желательно), что будет несколько версий cross-gcc. В каждую из них пихать binutils как-то не вполне разумно.

(In reply to Alexey Sheplyakov from comment #24)
> > > 1) /usr/lib/gcc/aarch64-linux-gnu/8 предназначена для компонент собственно
> > > gcc (cc1plus, collect2, и вот это все)
> > 
> > Если gcc начинает поиск с /usr/lib/gcc/aarch64-linux-gnu/8/as, значит, это
> > вполне подходящее место для того, чтобы этот файл существовал.
> 
> Нет. Это значит, что на тех ОС, где системным ассемблером пользоваться не
> выходит (Solaris, например), в этом месте gcc ожидает найти GNU as

Здесь аналогичный случай: системный as не подходит, потому что он нативный.

> > > 2) Тогда cross-binutils должен будет как-то узнать, какие возможны версии gcc
> > 
> > Зачем?  Если паковать /usr/lib/gcc/aarch64-linux-gnu/8/as, то в составе
> > cross-gcc, поскольку им будет эксклюзивно пользоваться cross-gcc.
> 
> 1) Предположение неверное. Ассемблером пользуются, например, люди, которые
> пишут оптимизированные реализации прямо на ассемблере. (И да, эти люди тоже
> ожидают найти ассемблер в /usr/$target/bin)

Те, ожидают, что кроссовый компилятор называется $target-gcc, наверняка в курсе, что кроссовый ассемблер называется $target-as.

/usr/$target - это Debian-specific, у нас application subdirectories непосредственно в /usr не должно быть.

> 2) Вполне возможно (и даже желательно), что будет несколько версий
> cross-gcc. В каждую из них пихать binutils как-то не вполне разумно.

Не binutils, а зависимость на неё, например, путём размещения ссылок.

(In reply to Dmitry V. Levin from comment #25)

> /usr/$target - это Debian-specific

Во-первых, нет. Оно gcc-specific, потому /usr/$target есть в любом дистрибутиве, где есть GCC как кросс-компилятор. Вот, например, Fedora: https://koji.fedoraproject.org/koji/rpminfo?rpmID=19949822

А во-вторых, Вы так говорите, будто "Debian-specific" -- это что-то плохое.

> у нас application subdirectories непосредственно в /usr не должно быть.

"Теория Маркса верна, потому что она всесильна", ага. (или наоборот - "всесильна, потому что верна" - уже успел забыть)

У нас не должно быть правил, которые непосредственно создают проблемы на ровном месте.

(Ответ для Alexey Sheplyakov на комментарий #26)

> У нас не должно быть правил, которые непосредственно создают проблемы на
> ровном месте.

Да. Но изменение правил -- это процесс, Вы можете инициировать обсуждение в devel@.
Пока же они действуют, не стоит их менять. 
Изменение действующих правил на ходу, -- это как раз и есть то, что предлагал помянутый Вами бывший классик.

(In reply to AEN from comment #27)
> (Ответ для Alexey Sheplyakov на комментарий #26)
> 
> > У нас не должно быть правил, которые непосредственно создают проблемы на
> > ровном месте.
> 
> Да. Но изменение правил -- это процесс, Вы можете инициировать обсуждение в
> devel@.
> Пока же они действуют, не стоит их менять.

Нет, не действуют:

$ rpm -ql avr-binutils | grep -e '^/usr/avr/' |wc -l
121

$ rpm -ql mingw64-binutils | grep 'mingw32/'
/usr/x86_64-pc-mingw32/bin
/usr/x86_64-pc-mingw32/bin/ar
/usr/x86_64-pc-mingw32/bin/as
/usr/x86_64-pc-mingw32/bin/dlltool
/usr/x86_64-pc-mingw32/bin/dllwrap
/usr/x86_64-pc-mingw32/bin/ld
/usr/x86_64-pc-mingw32/bin/ld.bfd
/usr/x86_64-pc-mingw32/bin/nm
/usr/x86_64-pc-mingw32/bin/objcopy
/usr/x86_64-pc-mingw32/bin/objdump
/usr/x86_64-pc-mingw32/bin/ranlib
/usr/x86_64-pc-mingw32/bin/readelf
/usr/x86_64-pc-mingw32/bin/strip
/usr/x86_64-pc-mingw32/bin/windres
/usr/x86_64-pc-mingw32/lib/ldscripts
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pe.x
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pe.xa
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pe.xbn
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pe.xe
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pe.xn
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pe.xr
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pe.xu
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pep.x
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pep.xa
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pep.xbn
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pep.xe
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pep.xn
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pep.xr
/usr/x86_64-pc-mingw32/lib/ldscripts/i386pep.xu

> Изменение действующих правил на ходу,

Правила на ходу меняет как раз таки господин Левин. Что характерно, без всяких обсуждений.


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

И здесь неверно. "Изменение действующих правил на ходу" (в соответствии со новыми данными экспериментов) - это наука. А раз и навсегда задать от балды правила и следовать им, даже если обстоятельства решительно поменялись, и правила перестали быть полезными - это догматика на манер "научного коммунизма".


Авторы советских учебников по научному коммунизму классиками никогда не являлись.

Научный коммунизм обсуждайте без меня, пожалуйста.

Прошло 9 месяцев. Кросс-компиляторы по-прежнему сломаны.

Господин Левин, будьте так добры, верните кросс-ассемблер в /usr/$target/bin/as

Исправлено в версии 10.3.1-alt1