40904 2021-09-13 12:49:45 +0300 [FR] binutils-source with patched sources 2021-09-29 14:58:21 +0300 1 1 4 Development Sisyphus binutils-source unstable all Linux CLOSED FIXED P5 enhancement --- 1 iv glebfm glebfm sin qa-sisyphus oldest_to_newest 202691 0 iv 2021-09-13 12:49:45 +0300 Мне, как мейнтейнеру cross-toolchain для mipsel и riscv64 хотелось бы, чтобы эти cross-toolchain'ы был по возможности максимально приближены к нашим дистрибутивным компиляторам на этих архитектурах. В частности, это касается патчей: перенос и повторное применение всех патчей с binutils, gcc и glibc -- это непростая и механическая работа, которой хотелось бы избежать. В связи с этим я предлагаю запаковать исходники такими, какими они получились в результате работы секции %pre, например так: http://git.altlinux.org/people/iv/packages/binutils.git?a=commit;h=e66b62761d439e9cf8ed5ef7bd9b6467629858da Сейчас binutils-source при сборке используется только в cross-toolchain*, поэтому я предлагаю именно изменить этот подпакет; однако если текущая семантика binutils-source важна, я прошу сделать новый подпакет. P.S. Естественно, я хочу того же от glibc-source и gcc-source. binutils просто первый по алфавиту. 203058 1 iv 2021-09-22 08:45:30 +0300 Уважаемые мейнтейнеры binutils! Пожалуйста, напишите, как вы относитесь к этой задаче. Стоит ли мне ожидать, что такое и/или подобное изменение будет сделано в binutils (а также gcc и glibc) или мне нужно идти другим путём? Если стóит, то могу ли я что-то сделать чтобы приблизить этот момент? Спасибо. 203091 2 ldv 2021-09-22 12:09:38 +0300 (In reply to Ivan A. Melnikov from comment #0) > В связи с этим я предлагаю запаковать исходники такими, какими они > получились в результате работы секции %pre, например так: Мне нравится это предложение. > http://git.altlinux.org/people/iv/packages/binutils.git?a=commit; > h=e66b62761d439e9cf8ed5ef7bd9b6467629858da По технике: у tar есть параметр -C. 203093 3 iv 2021-09-22 12:47:22 +0300 (In reply to Dmitry V. Levin from comment #2) > > http://git.altlinux.org/people/iv/packages/binutils.git?a=commit; > > h=e66b62761d439e9cf8ed5ef7bd9b6467629858da > > По технике: у tar есть параметр -C. Я хотел им воспользоваться, но он не влияет на путь к архиву (аргумент -f): $ mkdir test $ cd test $ touch a.txt $ tar -C.. -cf t.tar test tar: test/t.tar: file is the archive; not dumped $ ls a.txt t.tar $ tar -tf t.tar test/ test/a.txt Можно конечно указать -cf "../%name-%version-%release.tar" или вычислить польный путь, но вариант с со сменой каталога показался мне более простым и понятным. 203096 4 glebfm 2021-09-22 13:42:25 +0300 Я был почему-то уверен, что патчи сейчас упакованы в пакет. Идея была в том, что некоторые патчи не стоит прикладывать на каких-то архитектурах. gnu.hash в binutils (сейчас мы его включаем через configure, но раньше это был патч, который на mips *не прикладывался*) и stack-protector в gcc не поддерживаются на некоторых архитектурах. (В glibc таких патчей нет и скорее всего не будет никогда, к тому же все наши патчи и так применены в tarball-е, который лежит в glibc-source.) Применение таких патчей в архиве значило бы, что на таких архитектурах нужно всё равно приносить эти патчи с собой, чтобы их *откатить*. Мы точно хотим именно этого? Не разумнее ли положить патчи в пакет и для большей части архитектур сделать autopatch или его аналог в cross-toolchain? 203098 5 iv 2021-09-22 14:25:00 +0300 (In reply to Gleb F-Malinovskiy from comment #4) > В glibc таких патчей нет и скорее всего не будет никогда, > к тому же все наши патчи и так применены в tarball-е, > который лежит в glibc-source. Да, в glibc в этом плане уже всё хорошо. Мне бы хотелось лишь зафиксировать пожелание, чтобы оно так и оставалось в следующих сборках. > Применение таких патчей в архиве значило бы, что на таких архитектурах нужно > всё равно приносить эти патчи с собой, чтобы их *откатить*. Мы точно хотим > именно этого? Да. *Если* такие патчи снова появятся. > Не разумнее ли положить патчи в пакет и для большей части > архитектур сделать autopatch или его аналог в cross-toolchain? Я не придумал аналога autopatch, который бы учитывал разный порядок патчей, разные -p в %patchN и, например, sed'а который был в binutils 2.35. А ещё нравится идея того, что "binutils-source -- это те исходники, из которых мы собрали binutils, и делайте с ними что хотите". Я, как ответсвенный за тулчейн на mipsel и riscv64 (и некроссового тоже), знаю, что я хочу с ними сделать. А вот проверять при каждом обновлении, правильно ли я применил все нужные патчи, как-то слишком tedious и error-prone. 203101 6 ldv 2021-09-22 15:49:24 +0300 (In reply to Gleb F-Malinovskiy from comment #4) > Я был почему-то уверен, что патчи сейчас упакованы в пакет. > > Идея была в том, что некоторые патчи не стоит прикладывать на каких-то > архитектурах. gnu.hash в binutils (сейчас мы его включаем через configure, > но раньше это был патч, который на mips *не прикладывался*) и > stack-protector в gcc не поддерживаются на некоторых архитектурах. (В glibc > таких патчей нет и скорее всего не будет никогда, к тому же все наши патчи и > так применены в tarball-е, который лежит в glibc-source.) На мой взгляд, пакет binutils выиграл бы от перехода на ту схему сопровождения патчей, которая сейчас используется в пакете glibc. На самом деле эта схема в том или ином виде и так уже используется "под капотом". В качестве побочного эффекта вопрос с binutils-source решился бы сам собой. 203110 7 glebfm 2021-09-22 17:41:24 +0300 (In reply to Ivan A. Melnikov from comment #5) > (In reply to Gleb F-Malinovskiy from comment #4) > > В glibc таких патчей нет и скорее всего не будет никогда, > > к тому же все наши патчи и так применены в tarball-е, > > который лежит в glibc-source. > > Да, в glibc в этом плане уже всё хорошо. Мне бы хотелось лишь зафиксировать > пожелание, чтобы оно так и оставалось в следующих сборках. > > > Применение таких патчей в архиве значило бы, что на таких архитектурах нужно > > всё равно приносить эти патчи с собой, чтобы их *откатить*. Мы точно хотим > > именно этого? > > Да. *Если* такие патчи снова появятся. Это неизбежно случится, если мы захотим собрать кросс-тулчейн для архитектур, которые у нас не поддерживаются, среди них есть разная степень поддержки некоторых функций. > > Не разумнее ли положить патчи в пакет и для большей части > > архитектур сделать autopatch или его аналог в cross-toolchain? > > Я не придумал аналога autopatch, который бы учитывал разный порядок патчей, > разные -p в %patchN и, например, sed'а который был в binutils 2.35. > > А ещё нравится идея того, что "binutils-source -- это те исходники, из > которых мы собрали binutils, и делайте с ними что хотите". Я, как > ответсвенный за тулчейн на mipsel и riscv64 (и некроссового тоже), знаю, что > я хочу с ними сделать. А вот проверять при каждом обновлении, правильно ли я > применил все нужные патчи, как-то слишком tedious и error-prone. Да, этот подход естественным образом приводит к тому, что вместе с исходниками и патчами нужно было бы паковать инфломацию о том, как и в каком порядке их прикладывать, а это не то, что мы хотим делать. (In reply to Dmitry V. Levin from comment #6) > На мой взгляд, пакет binutils выиграл бы от перехода на ту схему > сопровождения патчей, > которая сейчас используется в пакете glibc. > На самом деле эта схема в том или ином виде и так уже используется "под > капотом". > В качестве побочного эффекта вопрос с binutils-source решился бы сам собой. Согласен. Да в общем-то понятно, что и в случае gcc можно применить этот же подход, у gcc даже апстрим уже в git-е наконец. :) 203171 8 iv 2021-09-23 14:49:45 +0300 (In reply to Gleb F-Malinovskiy from comment #7) > (In reply to Ivan A. Melnikov from comment #5) > > (In reply to Gleb F-Malinovskiy from comment #4) > > > Применение таких патчей в архиве значило бы, что на таких архитектурах нужно > > > всё равно приносить эти патчи с собой, чтобы их *откатить*. Мы точно хотим > > > именно этого? > > > > Да. *Если* такие патчи снова появятся. > > Это неизбежно случится, если мы захотим собрать кросс-тулчейн для > архитектур, которые у нас не поддерживаются, среди них есть разная степень > поддержки некоторых функций. Такие архитекуры не принципиально синхронизировать с тулчейном Сизифа (или соответствующего бранча); использование для них gcc-source/binutils-source/glibc-source не кажется мне оправданным. У меня, например, были бы немного другие пожелания к кросс-тулчейну если бы полученные бинарники не должны бы были работать в Альте. 203173 9 glebfm 2021-09-23 15:06:00 +0300 (In reply to Ivan A. Melnikov from comment #8) > Такие архитекуры не принципиально синхронизировать с тулчейном Сизифа (или > соответствующего бранча); использование для них > gcc-source/binutils-source/glibc-source не кажется мне оправданным. У меня, > например, были бы немного другие пожелания к кросс-тулчейну если бы > полученные бинарники не должны бы были работать в Альте. На самом деле, когда делались -source подпакеты задача сборки бинарников, которые должны работать в Альте не стояла на самом деле, идея была в том, чтобы собрать какие-нибудь кросс-тулчейны для как можно большего количества архитектур. 203341 10 repository-robot 2021-09-29 14:58:21 +0300 binutils-1:2.37-alt2 -> sisyphus: Wed Sep 29 2021 Gleb F-Malinovskiy <glebfm@altlinux> 1:2.37-alt2 - Changed build scheme to git branches instead of patches (ALT#40904). - Fixed preserving dates in ar archives processed with strip/objcopy with -p/--preserve-dates option. - Fixed FTBFS with gcc 11 (by switching some test back to DWARF version 4).