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.
Может быть, это будет полезно: https://fedora.pkgs.org/31/fedora-updates-armhfp/llvm-9.0.1-6.fc31.armv7hl.rpm.html
llvm 9.0 нужно удалить (я уже давно пытаюсь это сделать), все что с ним собрано, пересобрать с llvm 10.0
(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 для сборки.
не совсем так 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 у меня нет
Сборочница armh у Вас есть. Она поднимается на любом одноплатнике aarch64. Но, возможно, проще пересобрать эти пакеты.
(Ответ для AEN на комментарий #5) > Сборочница armh у Вас есть. Она поднимается на любом одноплатнике aarch64. есть, точнеее были. целых два. но сейчас они оба выключены и физического доступа к ним у меня нет > Но, возможно, проще пересобрать эти пакеты. конечно проще, хотя бы для того что бы не делать работу на выброс
(Ответ для Valery Inozemtsev на комментарий #4) > castxml darktemplar @everybody > > самое время заняться исправлением этих 9-ти пакетов. чинить сборку llvm 9.0 > вообще смысла не вижу, да и сборочницы на armh у меня нет А с castxml что-то не так? Насколько мне известно, с пересборкой проблем нет.
(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. Выводы делайте сами.
(Ответ для 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)
(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 - страдайте.
(Ответ для Dmitry V. Levin на комментарий #10) > Не хотели сделать так, как в gcc llvm не gcc, апстрим не предполагает иметь одновременно несколько версий девел пакетов (как минимум хидеры пересекаются). а вот иметь предсказуемое поведение apt'а очень бы хотелось > - страдайте. страдайте
(In reply to Valery Inozemtsev from comment #11) > (Ответ для Dmitry V. Levin на комментарий #10) > > Не хотели сделать так, как в gcc > > llvm не gcc, апстрим не предполагает иметь одновременно несколько версий > девел пакетов (как минимум хидеры пересекаются). а вот иметь предсказуемое > поведение apt'а очень бы хотелось Апстриму llvm вообще пофиг. Если мы собираем llvm в репозиторий, то это наша задача - обеспечить, чтобы у нас работало так, как надо нам. > страдайте Мантейнер не имеет права давать такой ответ.
(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
> it blocks rebuild (with libffi.so.7 instead of libffi.so.6) It's linux (c)
(In reply to Michael Shigorin from comment #14) > > it blocks rebuild (with libffi.so.7 instead of libffi.so.6) > It's linux (c) Нет, это перекладывание проблем поддержки нишевых архитектур на мантейнеров популярных архитектур.
(Ответ для Dmitry V. Levin на комментарий #12) > как надо нам. непредсказуемое поведение apt'а это так надо нам? > > страдайте > > Мантейнер не имеет права давать такой ответ. тогда ждите когда мантейнер сделает "как в gcc"
(In reply to Valery Inozemtsev from comment #16) > (Ответ для Dmitry V. Levin на комментарий #12) > > как надо нам. > > непредсказуемое поведение apt'а это так надо нам? Оно вполне предсказуемое: когда не указана версия, apt выбирает того провайдера, имя которого лексикографически круче. На это поведение многое было раньше завязано, когда gcc собирался по прежней схеме. > > > страдайте > > > > Мантейнер не имеет права давать такой ответ. > > тогда ждите когда мантейнер сделает "как в gcc" Когда примерно наступит этот празник?
(Ответ для 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
(Ответ для 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
(Ответ для 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 и что останавливает?
(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.
[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. Предлагайте решение проблемы. У меня его нет
http://git.altlinux.org/tasks/256127/build/100/armh/log
(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, у меня тоже нет.
А как fedora собирает?
(In reply to AEN from comment #25) > А как fedora собирает? Федора в конце января перешла с llvm9 на llvm10.
в rawhide llvm9.0 есть от 2020-02-26 и на сколько он собирающийся нам не известно
Потому и нам надо переходить, разве нет?
несколько дней назад llvm9.0-9.0.1-alt3.src.rpm был успешно пересобран без изменений на старой сборочнице. Не нужно далеко ходить, чтобы выяснить разницу.
http://static.skaip.su/img/emoticons/180x180/f6fcff/headbang.gif
(In reply to Sergey Bolshakov from comment #29) > несколько дней назад llvm9.0-9.0.1-alt3.src.rpm был успешно пересобран без > изменений на старой сборочнице. Не нужно далеко ходить, чтобы выяснить > разницу. И кстати говоря, Дмитрию об этом прекрасно известно, удивительно, что этот факт тут не упомянут.
(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 не так.
(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
вот и поговорили... я вижу единственный вариант - удалить llvm9.0 за ненадобностью. баги развесить на те 9-ть пакетов которые его хотя
хотя = хотят
Развесьте, пожалуйста. Меня в сс: Но с разницей между старой и новой сборочницей тоже хорошо бы разобраться.
(In reply to AEN from comment #36) > Но с разницей между старой и новой сборочницей тоже хорошо бы разобраться. Да. Я уже потратил на это больше времени, чем планировал, у меня не получилось, но я надеюсь, что Сергей справится.
FYI https://lists.altlinux.org/pipermail/devel/2020-August/211494.html
Это хорошо. Но полагаю, что Вы тоже не хотите возвращать armh на старую сборочницу. :) Потому надо разбираться. Кстати, та же проблема с памятью на сборочнице mipsel, хоть она и отдельная.
(In reply to AEN from comment #39) > Кстати, та же проблема с памятью на сборочнице mipsel, хоть она и отдельная. Проблема нехватки 32-битного адресного пространства обычно проявляется и на x86.
(Ответ для Dmitry V. Levin на комментарий #40) > (In reply to AEN from comment #39) > > Кстати, та же проблема с памятью на сборочнице mipsel, хоть она и отдельная. > > Проблема нехватки 32-битного адресного пространства обычно проявляется и на > x86. Кто бы мог подумать. :) Но там она решается.
(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
(In reply to AEN from comment #41) > (Ответ для Dmitry V. Levin на комментарий #40) > > (In reply to AEN from comment #39) > > > Кстати, та же проблема с памятью на сборочнице mipsel, хоть она и отдельная. > > > > Проблема нехватки 32-битного адресного пространства обычно проявляется и на > > x86. > Кто бы мог подумать. :) > Но там она решается. Откуда вы знаете? Может быть, она там не проявляется? :)
(Ответ для 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-ной архитектуре ?! :)
(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.
Добавил мейнтейнера
https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-August/579288.html
