Summary: | pkg-config: ошибка пересборки на архитектуре armh | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Alexey Sheplyakov <asheplyakov> |
Component: | pkg-config | Assignee: | placeholder <placeholder> |
Status: | NEW --- | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P5 | CC: | at, glebfm, iv, ldv, nir, placeholder, rider, shrek, sin |
Version: | unstable | ||
Hardware: | arm | ||
OS: | Linux | ||
Bug Depends on: | |||
Bug Blocks: | 45707 |
Description
Alexey Sheplyakov
2023-03-31 18:52:47 MSK
Можно, конечно, тупо пересобрать сломавшиеся пакеты (благо их немного). Но лучше бы понять: 1) Причину такого изменения, 2) Насколько оно желательно (или нет) Мы выяснили, что это стало следствием https://git.savannah.gnu.org/cgit/config.git/commit/?id=ee9898641088ae9169de0453ce475d371f9d5016 Как видно, в репозитории с этим нет консистентности: $ grep -F armh-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut -f2 |sort -u |wc -l 128 $ grep -F armv7l-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut -f2 |sort -u |wc -l 41 (Ответ для Dmitry V. Levin на комментарий #2) > Мы выяснили, что это стало следствием > https://git.savannah.gnu.org/cgit/config.git/commit/ > ?id=ee9898641088ae9169de0453ce475d371f9d5016 > > Как видно, в репозитории с этим нет консистентности: > $ grep -F armh-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut -f2 > |sort -u |wc -l > 128 Это то, что собиралось с gnu-config до коммита ee9898641088ae9169de0453ce475d371f9d5016. > $ grep -F armv7l-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut > -f2 |sort -u |wc -l > 41 А это - то, что успело собраться с gnu-config, в котором уже есть коммит ee9898641088ae9169de0453ce475d371f9d5016. Даже не знаю, что делать. 1. Если оставить gnu-config как есть, то при следующей пересборке gcc, binutils, у них ВНЕЗАПНО изменится триплет. 2. С другой стороны, условно низкоуровневый код (gmp, например) хорошо знает, что такое armv7l-*-linux-gnueabi, а вот что такое armh-*-linux-gnueabi - как-то не очень. Из-за этого configure может решить не использовать ассемблерные реализации, или вообще сказать - а я не знаю, что это за платформа такая. (In reply to Alexey Sheplyakov from comment #3) > (Ответ для Dmitry V. Levin на комментарий #2) > > Мы выяснили, что это стало следствием > > https://git.savannah.gnu.org/cgit/config.git/commit/ > > ?id=ee9898641088ae9169de0453ce475d371f9d5016 > > > > Как видно, в репозитории с этим нет консистентности: > > $ grep -F armh-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut -f2 > > |sort -u |wc -l > > 128 > > Это то, что собиралось с gnu-config до коммита > ee9898641088ae9169de0453ce475d371f9d5016. > > > $ grep -F armv7l-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut > > -f2 |sort -u |wc -l > > 41 > > А это - то, что успело собраться с gnu-config, в котором уже есть коммит > ee9898641088ae9169de0453ce475d371f9d5016. > > Даже не знаю, что делать. > > 1. Если оставить gnu-config как есть, то при следующей пересборке gcc, > binutils, у них ВНЕЗАПНО изменится триплет. Этот коммит в Сизифе с конца позапрошлого года, за это время весь тулчейн уже пересобирался. > 2. С другой стороны, условно низкоуровневый код (gmp, например) хорошо > знает, что такое armv7l-*-linux-gnueabi, а вот что такое > armh-*-linux-gnueabi - как-то не очень. > Из-за этого configure может решить не использовать ассемблерные > реализации, или вообще сказать - а я не знаю, что это за платформа такая. Жалобы на это и послужили причиной того коммита в gnu config. (Ответ для Dmitry V. Levin на комментарий #4) > (In reply to Alexey Sheplyakov from comment #3) > > (Ответ для Dmitry V. Levin на комментарий #2) > > > Мы выяснили, что это стало следствием > > > https://git.savannah.gnu.org/cgit/config.git/commit/ > > > ?id=ee9898641088ae9169de0453ce475d371f9d5016 > > > > > > Как видно, в репозитории с этим нет консистентности: > > > $ grep -F armh-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut -f2 > > > |sort -u |wc -l > > > 128 > > > > Это то, что собиралось с gnu-config до коммита > > ee9898641088ae9169de0453ce475d371f9d5016. > > > > > $ grep -F armv7l-alt-linux-gnueabi Sisyphus/armh/base/contents_index |cut > > > -f2 |sort -u |wc -l > > > 41 > > > > А это - то, что успело собраться с gnu-config, в котором уже есть коммит > > ee9898641088ae9169de0453ce475d371f9d5016. > > > > Даже не знаю, что делать. > > > > 1. Если оставить gnu-config как есть, то при следующей пересборке gcc, > > binutils, у них ВНЕЗАПНО изменится триплет. > > Этот коммит в Сизифе с конца позапрошлого года, за это время весь тулчейн > уже пересобирался. Отлично. Значит последствия не столь страшны, как я себе их представлял. > > 2. С другой стороны, условно низкоуровневый код (gmp, например) хорошо > > знает, что такое armv7l-*-linux-gnueabi, а вот что такое > > armh-*-linux-gnueabi - как-то не очень. > > Из-за этого configure может решить не использовать ассемблерные > > реализации, или вообще сказать - а я не знаю, что это за платформа такая. > > Жалобы на это и послужили причиной того коммита в gnu config. Значит, просто пересобираю в задании 317766 пострадавшие пакеты (ImageMagick, libfreetype)? (In reply to Alexey Sheplyakov from comment #5) > Значит, просто пересобираю в задании 317766 пострадавшие пакеты > (ImageMagick, libfreetype)? Да. (Ответ для Dmitry V. Levin на комментарий #6) > (In reply to Alexey Sheplyakov from comment #5) > > Значит, просто пересобираю в задании 317766 пострадавшие пакеты > > (ImageMagick, libfreetype)? > > Да. Попробовал. Стало ещё хуже: https://git.altlinux.org/tasks/317766/logs/events.6.1.log 2023-Apr-01 00:50:58 :: unmets: armh +492 -0 =504 2023-Apr-01 00:50:59 :: dependencies check FAILED 2023-Apr-01 00:50:59 :: task #317766 for sisyphus FAILED Для сборки libfreetype требуется libharbuzz-devel, см. (https://git.altlinux.org/srpms/l/libfreetype.git?p=libfreetype.git;a=blob;f=libfreetype.spec;h=aede1044d42071043915d690676109114bdf9676;hb=7b26e395ccd157a5cd52721554d3be538cba2d94#l26 А libharfbuzz-devel среди прочего зависит от libfreetype-devel: $ apt-cache show libharfbuzz-devel | grep -e '^Depends' | tr ',' '\n' Depends: /usr/lib64/pkgconfig glib2-devel libfreetype-devel libgraphite2-devel libicu-devel pkgconfig(glib-2.0) pkgconfig(gobject-2.0) libharfbuzz-icu (= 3.2.0-alt1:p10+310099.70.8.1) libharfbuzz-gobject (= 3.2.0-alt1:p10+310099.70.8.1) Чтобы пересобрать libfreetype-devel, нужно установить libfreetype-devel, а у libfreetype-devel сломана зависимость (от /usr/bin/armh-alt-linux-gnueabi-pkg-config) Значит, придётся фиксить сборку пакета libfreetype, например, путём добавления export PKG_CONFIG=pkg-config перед %configure. Вообще devel-пакеты совершенно напрасно зашивают путь к pkg-config, да ещё и архитектурно-зависимый. (Ответ для Dmitry V. Levin на комментарий #8) > Значит, придётся фиксить сборку пакета libfreetype, например, путём > добавления > export PKG_CONFIG=pkg-config > перед %configure. Помогло. > Вообще devel-пакеты совершенно напрасно зашивают путь к pkg-config, да ещё и > архитектурно-зависимый. Нет, не напрасно, а для поддержки кросс-компиляции (ПО, использующего данную библиотеку). Другое дело, что скрипт freetype-config сам по себе плохо сочетается с кросс-компиляцией -- кто ж добавляет в PATH $SYSROOT/bin? Но наши devel пакеты для кросс-компиляции (а точнее установки в SYSROOT) всё равно непригодны - в .pc файлах добрые люди удалили ${libdir} из Libs. (Ответ для Alexey Sheplyakov на комментарий #9) > (Ответ для Dmitry V. Levin на комментарий #8) > > Значит, придётся фиксить сборку пакета libfreetype, например, путём > > добавления > > export PKG_CONFIG=pkg-config > > перед %configure. > > Помогло. > > > Вообще devel-пакеты совершенно напрасно зашивают путь к pkg-config, да ещё и > > архитектурно-зависимый. > > Нет, не напрасно, а для поддержки кросс-компиляции (ПО, использующего данную > библиотеку). Интересно - а почему это происходит только на armh? Что-то я листал листал вашу переписку и так и не понял - вот этот изменение в ImageMagick оно чем обусловлено? +export PKG_CONFIG=pkg-config %configure \ Я правильно понимаю, что в devel пакет влетает прямой путь к pkg-config ? Может быть чинить это надо не таким способом, а где-то в autotools ? (In reply to Anton Farygin from comment #11) > Что-то я листал листал вашу переписку и так и не понял - вот этот изменение > в ImageMagick оно чем обусловлено? > > +export PKG_CONFIG=pkg-config > %configure \ > > Я правильно понимаю, что в devel пакет влетает прямой путь к pkg-config ? Да, пакет во время сборки сперва спрашивает полный путь к pkg-config (имеет на это право), а потом зачем-то зашивает этот полный путь в devel-пакет (а это уже лишнее). > Может быть чинить это надо не таким способом, а где-то в autotools ? См. комментари45727#c4 Непонятно, что тут чинить в autotools. Это проявляется только на armh, инвестировать в кото (In reply to Anton Farygin from comment #11) > Что-то я листал листал вашу переписку и так и не понял - вот этот изменение > в ImageMagick оно чем обусловлено? > > +export PKG_CONFIG=pkg-config > %configure \ > > Я правильно понимаю, что в devel пакет влетает прямой путь к pkg-config ? Да, пакет во время сборки сперва спрашивает полный путь к pkg-config (имеет на это право), а потом зачем-то зашивает этот полный путь в devel-пакет (а это уже лишнее). В Сизифе, видимо, всего 2 пакета, которые так сделали. > Может быть чинить это надо не таким способом, а где-то в autotools ? См. комментарий #c4. Вроде бы autotools всё делает правильно, просто у libfreetype-devel циклические сборочные зависимости, его нельзя просто так взять и пересобрать после пересборки pkg-config. Поскольку это проявляется только на armh (спасибо за инновационное название архитектуры), инвестировать в которую никто не собирается, скорее наоборот, проще сделать export PKG_CONFIG=pkg-config. (оказывается, багзилла иногда коммитит комментарии, когда делаешь Preview, зря она это делает) https://packages.altlinux.org/ru/tasks/317766/ остался один аппрув на freetype |