38791 2020-08-09 16:48:13 +0300 FTBFS on armh 2020-10-21 00:01:10 +0300 1 1 4 Development Sisyphus llvm9.0 unstable arm Linux CLOSED FIXED P5 blocker --- 1 ldv shrek aen cas darktemplaralt lav legion sbolshakov sin qa-sisyphus oldest_to_newest 191752 0 ldv 2020-08-09 16:48:13 +0300 llvm9.0-9.0.1-alt3 consistently fails to build on armh: https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/578316.html https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/578690.html https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/578698.html https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/578703.html This is especially BAD because it blocks rebuild (with libffi.so.7 instead of libffi.so.6) on all architectures, including non-armh ones. Please fix this ASAP. 191759 1 aen 2020-08-10 11:44:58 +0300 Может быть, это будет полезно: https://fedora.pkgs.org/31/fedora-updates-armhfp/llvm-9.0.1-6.fc31.armv7hl.rpm.html 191770 2 shrek 2020-08-10 17:00:22 +0300 llvm 9.0 нужно удалить (я уже давно пытаюсь это сделать), все что с ним собрано, пересобрать с llvm 10.0 191771 3 ldv 2020-08-10 17:05:13 +0300 (In reply to Valery Inozemtsev from comment #2) > llvm 9.0 нужно удалить (я уже давно пытаюсь это сделать), все что с ним > собрано, пересобрать с llvm 10.0 Пока что удаление llvm 9.0 очень далеко от завершения: $ grep -Fw llvm9.0-9.0.1-alt3.src.rpm ALT/Sisyphus/files/list/bin.list |cut -f1 |sort -u |join -11 -22 -o2.1 - beehive/stats/Sisyphus-x86_64/ufb-2 |sort -u |grep -v ^llvm9 |wc -l 502 Другими словами, более полутысячи пакетов ещё используют этот llvm для сборки. 191772 4 shrek 2020-08-10 17:21:13 +0300 не совсем так 2020-Aug-10 14:12:13 :: test-only task #256117 for sisyphus started by shrek: 2020-Aug-10 14:12:13 :: message: Deprecadet!!!_use_llvm10.0 #100 delete llvm9.0 [...] ACLs of affected packages (9): afl manowar darktemplar bpftrace vt @everybody castxml darktemplar @everybody ghc8.6.4 sin @everybody gnome-builder aris gnustep-dbuskit lakostis @everybody python-module-PySide2 cas @everybody python3-module-PySide2 cas @everybody qt5-tools zerg самое время заняться исправлением этих 9-ти пакетов. чинить сборку llvm 9.0 вообще смысла не вижу, да и сборочницы на armh у меня нет 191773 5 aen 2020-08-10 17:24:49 +0300 Сборочница armh у Вас есть. Она поднимается на любом одноплатнике aarch64. Но, возможно, проще пересобрать эти пакеты. 191774 6 shrek 2020-08-10 17:32:33 +0300 (Ответ для AEN на комментарий #5) > Сборочница armh у Вас есть. Она поднимается на любом одноплатнике aarch64. есть, точнеее были. целых два. но сейчас они оба выключены и физического доступа к ним у меня нет > Но, возможно, проще пересобрать эти пакеты. конечно проще, хотя бы для того что бы не делать работу на выброс 191775 7 darktemplaralt 2020-08-10 17:33:11 +0300 (Ответ для Valery Inozemtsev на комментарий #4) > castxml darktemplar @everybody > > самое время заняться исправлением этих 9-ти пакетов. чинить сборку llvm 9.0 > вообще смысла не вижу, да и сборочницы на armh у меня нет А с castxml что-то не так? Насколько мне известно, с пересборкой проблем нет. 191776 8 ldv 2020-08-10 17:41:44 +0300 (In reply to Aleksei Nikiforov from comment #7) > А с castxml что-то не так? Насколько мне известно, с пересборкой проблем нет. $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/castxml-0.3.4-alt1.src.rpm |grep -E '^(clang|llvm)' llvm-devel llvm-devel-static clang-devel clang-devel-static Однако в сборочной среде этого пакета нет llvm10, но есть llvm9. Выводы делайте сами. 191777 9 shrek 2020-08-10 17:54:13 +0300 (Ответ для Dmitry V. Levin на комментарий #8) > Однако в сборочной среде этого пакета нет llvm10, но есть llvm9. > Выводы делайте сами. потому что наш чудный apt считает что у пакета llvm9.0-devel-9.0.1-alt3 (который провайдит llvm-devel-9.0.1-alt3) версия выше чем у пакета llvm10.0-devel-10.0.0-alt2 (который провайдит llvm-devel-10.0.0-alt2) 191778 10 ldv 2020-08-10 17:56:00 +0300 (In reply to Valery Inozemtsev from comment #9) > (Ответ для Dmitry V. Levin на комментарий #8) > > Однако в сборочной среде этого пакета нет llvm10, но есть llvm9. > > Выводы делайте сами. > > потому что наш чудный apt считает что у пакета llvm9.0-devel-9.0.1-alt3 > (который провайдит llvm-devel-9.0.1-alt3) версия выше чем у пакета > llvm10.0-devel-10.0.0-alt2 (который провайдит llvm-devel-10.0.0-alt2) Вы не можете поменять поведение apt задним числом. Не хотели сделать так, как в gcc - страдайте. 191780 11 shrek 2020-08-10 18:03:55 +0300 (Ответ для Dmitry V. Levin на комментарий #10) > Не хотели сделать так, как в gcc llvm не gcc, апстрим не предполагает иметь одновременно несколько версий девел пакетов (как минимум хидеры пересекаются). а вот иметь предсказуемое поведение apt'а очень бы хотелось > - страдайте. страдайте 191782 12 ldv 2020-08-10 18:13:08 +0300 (In reply to Valery Inozemtsev from comment #11) > (Ответ для Dmitry V. Levin на комментарий #10) > > Не хотели сделать так, как в gcc > > llvm не gcc, апстрим не предполагает иметь одновременно несколько версий > девел пакетов (как минимум хидеры пересекаются). а вот иметь предсказуемое > поведение apt'а очень бы хотелось Апстриму llvm вообще пофиг. Если мы собираем llvm в репозиторий, то это наша задача - обеспечить, чтобы у нас работало так, как надо нам. > страдайте Мантейнер не имеет права давать такой ответ. 191784 13 ldv 2020-08-10 18:15:45 +0300 (In reply to Dmitry V. Levin from comment #8) > (In reply to Aleksei Nikiforov from comment #7) > > А с castxml что-то не так? Насколько мне известно, с пересборкой проблем нет. > > $ rpmquery -Rp /ALT/Sisyphus/files/SRPMS/castxml-0.3.4-alt1.src.rpm |grep -E > '^(clang|llvm)' > llvm-devel > llvm-devel-static > clang-devel > clang-devel-static > > Однако в сборочной среде этого пакета нет llvm10, но есть llvm9. > Выводы делайте сами. Если вы прибьёте туда clang10/llvm10/lld10, то не соберётся: https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/579067.html 191786 14 mike 2020-08-10 18:22:00 +0300 > it blocks rebuild (with libffi.so.7 instead of libffi.so.6) It's linux (c) 191787 15 ldv 2020-08-10 18:24:03 +0300 (In reply to Michael Shigorin from comment #14) > > it blocks rebuild (with libffi.so.7 instead of libffi.so.6) > It's linux (c) Нет, это перекладывание проблем поддержки нишевых архитектур на мантейнеров популярных архитектур. 191788 16 shrek 2020-08-10 18:27:30 +0300 (Ответ для Dmitry V. Levin на комментарий #12) > как надо нам. непредсказуемое поведение apt'а это так надо нам? > > страдайте > > Мантейнер не имеет права давать такой ответ. тогда ждите когда мантейнер сделает "как в gcc" 191789 17 ldv 2020-08-10 18:31:37 +0300 (In reply to Valery Inozemtsev from comment #16) > (Ответ для Dmitry V. Levin на комментарий #12) > > как надо нам. > > непредсказуемое поведение apt'а это так надо нам? Оно вполне предсказуемое: когда не указана версия, apt выбирает того провайдера, имя которого лексикографически круче. На это поведение многое было раньше завязано, когда gcc собирался по прежней схеме. > > > страдайте > > > > Мантейнер не имеет права давать такой ответ. > > тогда ждите когда мантейнер сделает "как в gcc" Когда примерно наступит этот празник? 191790 18 shrek 2020-08-10 18:40:22 +0300 (Ответ для Dmitry V. Levin на комментарий #17) > (In reply to Valery Inozemtsev from comment #16) > > (Ответ для Dmitry V. Levin на комментарий #12) > > > как надо нам. > > > > непредсказуемое поведение apt'а это так надо нам? > > Оно вполне предсказуемое: когда не указана версия, apt выбирает того > провайдера, имя которого лексикографически круче. На это поведение многое > было раньше завязано, когда gcc собирался по прежней схеме. > > > > > страдайте > > > > > > Мантейнер не имеет права давать такой ответ. > > > > тогда ждите когда мантейнер сделает "как в gcc" > > Когда примерно наступит этот празник? хз. врапер тупо берется из gcc-common, надо только хидеры по подкаталагам раскидать и научить его лазить в нужные места. но это никак не поможет собраться llvm9.0 на armh 191791 19 darktemplaralt 2020-08-10 19:04:00 +0300 (Ответ для Dmitry V. Levin на комментарий #13) > Если вы прибьёте туда clang10/llvm10/lld10, то не соберётся: > https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/579067. > html А вот это уже должно собраться, если собирать и с llvm10.0: http://git.altlinux.org/people/darktemplar/packages/?p=castxml.git;a=commitdiff;h=159f593751e9731e252596cea6a9ac7301aaf6ce 191793 20 shrek 2020-08-10 19:07:58 +0300 (Ответ для Aleksei Nikiforov на комментарий #19) > (Ответ для Dmitry V. Levin на комментарий #13) > > Если вы прибьёте туда clang10/llvm10/lld10, то не соберётся: > > https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/579067. > > html > > А вот это уже должно собраться, если собирать и с llvm10.0: > http://git.altlinux.org/people/darktemplar/packages/?p=castxml.git; > a=commitdiff;h=159f593751e9731e252596cea6a9ac7301aaf6ce и что останавливает? 191794 21 ldv 2020-08-10 19:27:18 +0300 (In reply to Aleksei Nikiforov from comment #19) > (Ответ для Dmitry V. Levin на комментарий #13) > > Если вы прибьёте туда clang10/llvm10/lld10, то не соберётся: > > https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/579067. > > html > > А вот это уже должно собраться, если собирать и с llvm10.0: > http://git.altlinux.org/people/darktemplar/packages/?p=castxml.git; > a=commitdiff;h=159f593751e9731e252596cea6a9ac7301aaf6ce Попробуйте отправить это в Сизиф. Поскольку в сборочнице свои pkgpriorities, там можно закостылить llvm10 вместо llvm9. 191795 22 shrek 2020-08-10 19:46:47 +0300 [00:09:11] LLVM ERROR: out of memory [00:09:11] Stack dump: [00:09:11] 0. Running pass 'CallGraph Pass Manager' on module 'tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/ASTWriter.cpp.o'. [00:09:11] 1. Running pass 'Memory SSA' on function '@_ZN5clang15ASTRecordWriter7AddAttrEPKNS_4AttrE' [00:09:11] clang-9: error: unable to execute command: Aborted [00:09:11] clang-9: error: linker command failed due to signal (use -v to see invocation) [00:09:11] ninja: build stopped: subcommand failed. Предлагайте решение проблемы. У меня его нет 191796 23 shrek 2020-08-10 19:47:46 +0300 http://git.altlinux.org/tasks/256127/build/100/armh/log 191797 24 ldv 2020-08-10 19:49:26 +0300 (In reply to Valery Inozemtsev from comment #22) > [00:09:11] LLVM ERROR: out of memory > [00:09:11] Stack dump: > [00:09:11] 0. Running pass 'CallGraph Pass Manager' on module > 'tools/clang/lib/Serialization/CMakeFiles/obj.clangSerialization.dir/ > ASTWriter.cpp.o'. > [00:09:11] 1. Running pass 'Memory SSA' on function > '@_ZN5clang15ASTRecordWriter7AddAttrEPKNS_4AttrE' > [00:09:11] clang-9: error: unable to execute command: Aborted > [00:09:11] clang-9: error: linker command failed due to signal (use -v to > see invocation) > [00:09:11] ninja: build stopped: subcommand failed. > > Предлагайте решение проблемы. У меня его нет Поскольку "LLVM ERROR: out of memory" - это не cgroup memory limit, у меня тоже нет. 191798 25 aen 2020-08-10 19:52:04 +0300 А как fedora собирает? 191799 26 ldv 2020-08-10 19:55:56 +0300 (In reply to AEN from comment #25) > А как fedora собирает? Федора в конце января перешла с llvm9 на llvm10. 191800 27 shrek 2020-08-10 19:59:42 +0300 в rawhide llvm9.0 есть от 2020-02-26 и на сколько он собирающийся нам не известно 191801 28 aen 2020-08-10 20:02:27 +0300 Потому и нам надо переходить, разве нет? 191802 29 sbolshakov 2020-08-10 20:05:46 +0300 несколько дней назад llvm9.0-9.0.1-alt3.src.rpm был успешно пересобран без изменений на старой сборочнице. Не нужно далеко ходить, чтобы выяснить разницу. 191804 30 shrek 2020-08-10 20:06:29 +0300 http://static.skaip.su/img/emoticons/180x180/f6fcff/headbang.gif 191805 31 sbolshakov 2020-08-10 20:07:21 +0300 (In reply to Sergey Bolshakov from comment #29) > несколько дней назад llvm9.0-9.0.1-alt3.src.rpm был успешно пересобран без > изменений на старой сборочнице. Не нужно далеко ходить, чтобы выяснить > разницу. И кстати говоря, Дмитрию об этом прекрасно известно, удивительно, что этот факт тут не упомянут. 191806 32 ldv 2020-08-10 20:11:19 +0300 (In reply to Sergey Bolshakov from comment #31) > (In reply to Sergey Bolshakov from comment #29) > > несколько дней назад llvm9.0-9.0.1-alt3.src.rpm был успешно пересобран без > > изменений на старой сборочнице. Не нужно далеко ходить, чтобы выяснить > > разницу. > > И кстати говоря, Дмитрию об этом прекрасно известно, удивительно, что этот > факт тут не упомянут. Доказательств этому факту не представлено, так что я его за факт не считаю. В любом случае у меня нет идей, что там у вас на armh не так. 191807 33 sbolshakov 2020-08-10 20:15:32 +0300 (In reply to Dmitry V. Levin from comment #32) > (In reply to Sergey Bolshakov from comment #31) > > (In reply to Sergey Bolshakov from comment #29) > > > несколько дней назад llvm9.0-9.0.1-alt3.src.rpm был успешно пересобран без > > > изменений на старой сборочнице. Не нужно далеко ходить, чтобы выяснить > > > разницу. > > > > И кстати говоря, Дмитрию об этом прекрасно известно, удивительно, что этот > > факт тут не упомянут. > > Доказательств этому факту не представлено, так что я его за факт не считаю. > В любом случае у меня нет идей, что там у вас на armh не так. Ох. "какие ваши доказательства" штош, кокаинум: https://lioka.obninsk.ru/llvm9.0-9.0.1-alt3.src.rpm.log 191808 34 shrek 2020-08-10 20:16:09 +0300 вот и поговорили... я вижу единственный вариант - удалить llvm9.0 за ненадобностью. баги развесить на те 9-ть пакетов которые его хотя 191809 35 shrek 2020-08-10 20:16:55 +0300 хотя = хотят 191810 36 aen 2020-08-10 20:19:44 +0300 Развесьте, пожалуйста. Меня в сс: Но с разницей между старой и новой сборочницей тоже хорошо бы разобраться. 191811 37 ldv 2020-08-10 20:25:00 +0300 (In reply to AEN from comment #36) > Но с разницей между старой и новой сборочницей тоже хорошо бы разобраться. Да. Я уже потратил на это больше времени, чем планировал, у меня не получилось, но я надеюсь, что Сергей справится. 191812 38 sbolshakov 2020-08-10 20:37:46 +0300 FYI https://lists.altlinux.org/pipermail/devel/2020-August/211494.html 191813 39 aen 2020-08-10 20:42:45 +0300 Это хорошо. Но полагаю, что Вы тоже не хотите возвращать armh на старую сборочницу. :) Потому надо разбираться. Кстати, та же проблема с памятью на сборочнице mipsel, хоть она и отдельная. 191814 40 ldv 2020-08-10 21:46:59 +0300 (In reply to AEN from comment #39) > Кстати, та же проблема с памятью на сборочнице mipsel, хоть она и отдельная. Проблема нехватки 32-битного адресного пространства обычно проявляется и на x86. 191815 41 aen 2020-08-10 21:59:12 +0300 (Ответ для Dmitry V. Levin на комментарий #40) > (In reply to AEN from comment #39) > > Кстати, та же проблема с памятью на сборочнице mipsel, хоть она и отдельная. > > Проблема нехватки 32-битного адресного пространства обычно проявляется и на > x86. Кто бы мог подумать. :) Но там она решается. 191816 42 ldv 2020-08-10 22:04:16 +0300 (In reply to Dmitry V. Levin from comment #37) > (In reply to AEN from comment #36) > > Но с разницей между старой и новой сборочницей тоже хорошо бы разобраться. > > Да. Я уже потратил на это больше времени, чем планировал, у меня не > получилось, но я надеюсь, что Сергей справится. На всякий случай привожу статистику потребления памяти, собранную в середине прошлой недели: 1. $(nproc) == 64: $ cat /sys/fs/cgroup/memory/user/bee/$USER/memory.{max_usage_in_bytes,limit_in_bytes} 15928725504 33285996544 1. $(nproc) == 32: $ cat /sys/fs/cgroup/memory/user/bee/$USER/memory.{max_usage_in_bytes,limit_in_bytes} 9813012480 33285996544 3. $(nproc) == 16: $ cat /sys/fs/cgroup/memory/user/bee/$USER/memory.{max_usage_in_bytes,limit_in_bytes} 6542618624 33285996544 Во всех случаях сборка падала в одном и том же месте (см. ссылки в первом посте): [3622/3716] : && /usr/bin/clang++ -fPIC -pipe -frecord-gcc-switches -Wall -g0 -O2 -fomit-frame-pointer -march=armv7-a -mthumb -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -flto=thin -fno-common -Woverloaded-virtual -Wno-nested-anon-types -O2 -DNDEBUG -Wl,-z,defs -Wl,-z,nodelete -fuse-ld=lld -Wl,--color-diagnostics -Wl,--thinlto-cache-dir=/usr/src/RPM/BUILD/llvm-9.0.1.src/BUILD/lto.cache -Wl,-O3 -Wl,--gc-sections -shared -Wl,-soname,libclang-cpp.so.9 -o lib/libclang-cpp.so.9 ... [armh] FAILED: lib/libclang-cpp.so.9 191817 43 ldv 2020-08-10 22:05:12 +0300 (In reply to AEN from comment #41) > (Ответ для Dmitry V. Levin на комментарий #40) > > (In reply to AEN from comment #39) > > > Кстати, та же проблема с памятью на сборочнице mipsel, хоть она и отдельная. > > > > Проблема нехватки 32-битного адресного пространства обычно проявляется и на > > x86. > Кто бы мог подумать. :) > Но там она решается. Откуда вы знаете? Может быть, она там не проявляется? :) 191818 44 legion 2020-08-10 22:14:58 +0300 (Ответ для Dmitry V. Levin на комментарий #42) > > Во всех случаях сборка падала в одном и том же месте (см. ссылки в первом > посте): > [3622/3716] : && /usr/bin/clang++ -fPIC -pipe -frecord-gcc-switches -Wall > -g0 -O2 -fomit-frame-pointer -march=armv7-a -mthumb -fPIC > -fvisibility-inlines-hidden -Werror=date-time > -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra > -Wno-unused-parameter -Wwrite-strings -Wcast-qual > -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough > -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor > -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color > -ffunction-sections -fdata-sections -flto=thin -fno-common > -Woverloaded-virtual -Wno-nested-anon-types -O2 -DNDEBUG -Wl,-z,defs > -Wl,-z,nodelete -fuse-ld=lld -Wl,--color-diagnostics > -Wl,--thinlto-cache-dir=/usr/src/RPM/BUILD/llvm-9.0.1.src/BUILD/lto.cache > -Wl,-O3 -Wl,--gc-sections -shared -Wl,-soname,libclang-cpp.so.9 -o > lib/libclang-cpp.so.9 ... > [armh] FAILED: lib/libclang-cpp.so.9 -flto=thin на 32-ной архитектуре ?! :) 191819 45 ldv 2020-08-11 00:46:59 +0300 (In reply to Valery Inozemtsev from comment #34) > вот и поговорили... я вижу единственный вариант - удалить llvm9.0 за > ненадобностью. баги развесить на те 9-ть пакетов которые его хотя bpftrace пересобрал мантейнер, bcc исправил мантейнер, castxml исправил мантейнер, все остальные, кроме ghc8.6.4, я отправил на пересборку с llvm10. Таким образом, остаётся один ghc8.6.4, в котором написана вот такая ересь: # llvm needs for unregisterised architectures %ifarch armh %define llvm_version 9.0 %else %define llvm_version 7.0 %endif ... %ifarch armh aarch64 BuildRequires: llvm%llvm_version Requires: llvm%llvm_version %endif Избавьте нас от неё, пожалуйста, и llvm9 можно будет отправить на покой, так и не узнав, почему он не пересобирается на armh. 191820 46 aen 2020-08-11 00:55:00 +0300 Добавил мейнтейнера 191895 47 ldv 2020-08-14 01:46:03 +0300 https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/579288.html