* [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 [not found] <5dc3c4b8.1c69fb81.ff4f2.2a4cSMTPIN_ADDED_MISSING@mx.google.com> @ 2019-11-09 10:40 ` Romain Naour 2019-11-09 12:01 ` Yann E. MORIN 2019-11-09 22:29 ` Peter Seiderer 0 siblings, 2 replies; 8+ messages in thread From: Romain Naour @ 2019-11-09 10:40 UTC (permalink / raw) To: buildroot Hi Yann, All, Le 07/11/2019 ? 08:16, Thomas Petazzoni a ?crit?: > Hello, > > Recent build failures and runtime-tests failures > ================================================ > > This is the list of Buildroot build failures that occurred on > 2019-11-06, and for which you are a registered architecture developer, > package developer or defconfig developer. This list also include > runtime tests failures. Please help us improving the quality of > Buildroot by investigating those build failures and sending patches to > fix them. Thanks! > > Results for the 'master' branch > ------------------------------- > > Build failures related to your packages: > > arch | reason | url > -------------+--------------------------------+--------------------------------------------------------------------------------- > mips64el | host-llvm-9.0.0 | http://autobuild.buildroot.net/results/d3aa03ca7085727d0794228178c7744859900137 This is weird since mips is not (yet) supported by Buildroot's llvm package (see BR2_PACKAGE_LLVM_ARCH_SUPPORTS). host-llvm dependency seems trigged by another package at Makefile level without being llvm/clang at Kconfig level. Yann, the issue seems related to qt5tools for Qt 5.12 [1]. Since it now depends on libclang, BR2_PACKAGE_QT5TOOLS_QDOC_TOOL must depends on BR2_PACKAGE_LLVM_ARCH_SUPPORTS (at least). [1] https://git.buildroot.net/buildroot/commit/?id=57c1d3be4ecadd6802414a0943185c4ab6d82937 > arm | mesa3d-19.2.2 | http://autobuild.buildroot.net/results/891acd135b9d92067da83aee4c987e872137d07c gallium nouveau issue on ARM with uClibc and c++14: FAILED: src/gallium/drivers/nouveau/f590698@@nouveau at sta/codegen_nv50_ir_ra.cpp.o error: 'isinf' was not declared in this scope Best regards, Romain > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 2019-11-09 10:40 ` [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 Romain Naour @ 2019-11-09 12:01 ` Yann E. MORIN 2019-11-09 13:09 ` Romain Naour 2019-11-09 22:29 ` Peter Seiderer 1 sibling, 1 reply; 8+ messages in thread From: Yann E. MORIN @ 2019-11-09 12:01 UTC (permalink / raw) To: buildroot Romain, All, On 2019-11-09 11:40 +0100, Romain Naour spake thusly: > > mips64el | host-llvm-9.0.0 | http://autobuild.buildroot.net/results/d3aa03ca7085727d0794228178c7744859900137 > > This is weird since mips is not (yet) supported by Buildroot's llvm package (see > BR2_PACKAGE_LLVM_ARCH_SUPPORTS). > > host-llvm dependency seems trigged by another package at Makefile level without > being llvm/clang at Kconfig level. > > Yann, the issue seems related to qt5tools for Qt 5.12 [1]. > Since it now depends on libclang, BR2_PACKAGE_QT5TOOLS_QDOC_TOOL must depends on > BR2_PACKAGE_LLVM_ARCH_SUPPORTS (at least). This is a serious limitation in the host-llvm package, then. qt5tools wants llvm to build a tool (namely, qdoc) for the host, not the target. So it should not be bothered by whatever the target is. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 2019-11-09 12:01 ` Yann E. MORIN @ 2019-11-09 13:09 ` Romain Naour 2019-11-09 13:30 ` Thomas Petazzoni 2019-11-09 21:33 ` Yann E. MORIN 0 siblings, 2 replies; 8+ messages in thread From: Romain Naour @ 2019-11-09 13:09 UTC (permalink / raw) To: buildroot Yann, All, Le 09/11/2019 ? 13:01, Yann E. MORIN a ?crit?: > Romain, All, > > On 2019-11-09 11:40 +0100, Romain Naour spake thusly: >>> mips64el | host-llvm-9.0.0 | http://autobuild.buildroot.net/results/d3aa03ca7085727d0794228178c7744859900137 >> >> This is weird since mips is not (yet) supported by Buildroot's llvm package (see >> BR2_PACKAGE_LLVM_ARCH_SUPPORTS). >> >> host-llvm dependency seems trigged by another package at Makefile level without >> being llvm/clang at Kconfig level. >> >> Yann, the issue seems related to qt5tools for Qt 5.12 [1]. >> Since it now depends on libclang, BR2_PACKAGE_QT5TOOLS_QDOC_TOOL must depends on >> BR2_PACKAGE_LLVM_ARCH_SUPPORTS (at least). > > This is a serious limitation in the host-llvm package, then. > > qt5tools wants llvm to build a tool (namely, qdoc) for the host, not > the target. So it should not be bothered by whatever the target is. Well, It's the same problem as for using llvm/clang on the host to build some host tools. For your case you have to build hos-llvm with your host variant (x86_64 for example) (LLVM_TARGETS_TO_BUILD). But since we use the same LLVM_TARGET_ARCH for the host-llvm and llvm, we need to use -target x86_64-linux-gnu when using clang. See: http://lists.busybox.net/pipermail/buildroot/2019-November/265490.html Initially llvm was packaged as a cross-toolchain only. Here you want to use it as a native compiler. It's like if you want to build a host-gcc for you build machine instead of using the compiler provided by you distribution. In this case we probably can use clang provided by the build machine ? Best regards, Romain > > Regards, > Yann E. MORIN. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 2019-11-09 13:09 ` Romain Naour @ 2019-11-09 13:30 ` Thomas Petazzoni 2019-11-09 13:42 ` Romain Naour 2019-11-09 21:33 ` Yann E. MORIN 1 sibling, 1 reply; 8+ messages in thread From: Thomas Petazzoni @ 2019-11-09 13:30 UTC (permalink / raw) To: buildroot On Sat, 9 Nov 2019 14:09:50 +0100 Romain Naour <romain.naour@gmail.com> wrote: > Well, It's the same problem as for using llvm/clang on the host to build some > host tools. For your case you have to build hos-llvm with your host variant > (x86_64 for example) (LLVM_TARGETS_TO_BUILD). > > But since we use the same LLVM_TARGET_ARCH for the host-llvm and llvm, we need > to use -target x86_64-linux-gnu when using clang. Wouldn't it be more "natural" for clang to by default produce binaries for the host, and when you want to cross-compile, have to explicitly pass -target arm-something-something ? Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 2019-11-09 13:30 ` Thomas Petazzoni @ 2019-11-09 13:42 ` Romain Naour 0 siblings, 0 replies; 8+ messages in thread From: Romain Naour @ 2019-11-09 13:42 UTC (permalink / raw) To: buildroot Le 09/11/2019 ? 14:30, Thomas Petazzoni a ?crit?: > On Sat, 9 Nov 2019 14:09:50 +0100 > Romain Naour <romain.naour@gmail.com> wrote: > >> Well, It's the same problem as for using llvm/clang on the host to build some >> host tools. For your case you have to build hos-llvm with your host variant >> (x86_64 for example) (LLVM_TARGETS_TO_BUILD). >> >> But since we use the same LLVM_TARGET_ARCH for the host-llvm and llvm, we need >> to use -target x86_64-linux-gnu when using clang. > > Wouldn't it be more "natural" for clang to by default produce binaries > for the host, and when you want to cross-compile, have to explicitly > pass -target arm-something-something ? It's seems Valentin had some issues when LLVM_TARGET_ARCH is not the same for host-llvm and llvm, there is a comment about it: # It must be set to LLVM_TARGET_ARCH for host and target, otherwise we get # "No available targets are compatible for this triple" with llvmpipe when host # and target architectures are different. Valentin, do you remember ? Was It a runtime issue ? Best regards, Romain > > Thomas > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 2019-11-09 13:09 ` Romain Naour 2019-11-09 13:30 ` Thomas Petazzoni @ 2019-11-09 21:33 ` Yann E. MORIN 2019-11-17 19:22 ` Arnout Vandecappelle 1 sibling, 1 reply; 8+ messages in thread From: Yann E. MORIN @ 2019-11-09 21:33 UTC (permalink / raw) To: buildroot Romain, All, On 2019-11-09 14:09 +0100, Romain Naour spake thusly: > Le 09/11/2019 ? 13:01, Yann E. MORIN a ?crit?: > > On 2019-11-09 11:40 +0100, Romain Naour spake thusly: > >>> mips64el | host-llvm-9.0.0 | http://autobuild.buildroot.net/results/d3aa03ca7085727d0794228178c7744859900137 > >> This is weird since mips is not (yet) supported by Buildroot's llvm package (see > >> BR2_PACKAGE_LLVM_ARCH_SUPPORTS). > >> > >> host-llvm dependency seems trigged by another package at Makefile level without > >> being llvm/clang at Kconfig level. > >> > >> Yann, the issue seems related to qt5tools for Qt 5.12 [1]. > >> Since it now depends on libclang, BR2_PACKAGE_QT5TOOLS_QDOC_TOOL must depends on > >> BR2_PACKAGE_LLVM_ARCH_SUPPORTS (at least). > > > > This is a serious limitation in the host-llvm package, then. > > > > qt5tools wants llvm to build a tool (namely, qdoc) for the host, not > > the target. So it should not be bothered by whatever the target is. > > Well, It's the same problem as for using llvm/clang on the host to build some > host tools. For your case you have to build hos-llvm with your host variant > (x86_64 for example) (LLVM_TARGETS_TO_BUILD). qdoc is a host tool that scans qt-based source code, extracts the special comments, and generates the documentation. It does not generate target binary (afaik). It is only linked with libclang: $ readelf -d build/qt5tools-5.12.5/bin/qdoc Dynamic section at offset 0x229680 contains 34 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libclang.so.9] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] > But since we use the same LLVM_TARGET_ARCH for the host-llvm and llvm, we need > to use -target x86_64-linux-gnu when using clang. But if there is no target llvm built, we could just fallback to the host machine, then, no? Regards, Yann E. MORIN. > See: http://lists.busybox.net/pipermail/buildroot/2019-November/265490.html > > Initially llvm was packaged as a cross-toolchain only. Here you want to use it > as a native compiler. It's like if you want to build a host-gcc for you build > machine instead of using the compiler provided by you distribution. > > In this case we probably can use clang provided by the build machine ? > > Best regards, > Romain > > > > > Regards, > > Yann E. MORIN. > > > -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 2019-11-09 21:33 ` Yann E. MORIN @ 2019-11-17 19:22 ` Arnout Vandecappelle 0 siblings, 0 replies; 8+ messages in thread From: Arnout Vandecappelle @ 2019-11-17 19:22 UTC (permalink / raw) To: buildroot On 09/11/2019 22:33, Yann E. MORIN wrote: > Romain, All, > > On 2019-11-09 14:09 +0100, Romain Naour spake thusly: >> Le 09/11/2019 ? 13:01, Yann E. MORIN a ?crit?: >>> On 2019-11-09 11:40 +0100, Romain Naour spake thusly: >>>>> mips64el | host-llvm-9.0.0 | http://autobuild.buildroot.net/results/d3aa03ca7085727d0794228178c7744859900137 >>>> This is weird since mips is not (yet) supported by Buildroot's llvm package (see >>>> BR2_PACKAGE_LLVM_ARCH_SUPPORTS). >>>> >>>> host-llvm dependency seems trigged by another package at Makefile level without >>>> being llvm/clang at Kconfig level. >>>> >>>> Yann, the issue seems related to qt5tools for Qt 5.12 [1]. >>>> Since it now depends on libclang, BR2_PACKAGE_QT5TOOLS_QDOC_TOOL must depends on >>>> BR2_PACKAGE_LLVM_ARCH_SUPPORTS (at least). [snip] >> But since we use the same LLVM_TARGET_ARCH for the host-llvm and llvm, we need >> to use -target x86_64-linux-gnu when using clang. > > But if there is no target llvm built, we could just fallback to the host > machine, then, no? That would be by intuition as well. But looking at the details, I don't see the light yet... There are actually three variables that contain the target: LLVM_TARGET_ARCH LLVM_TARGETS_TO_BUILD LLVM_DEFAULT_TARGET_TRIPLE LLVM_TARGETS_TO_BUILD is easy: we should just always make sure that it contains the host in addition to the target. For the other two, I guess we could default them to host if target is not supported. However, that gives the weird situation that the default target (which I guess is the meaning of LLVM_TARGET_ARCH) is sometimes the host and sometimes the target... That feels... weird... So maybe it would make more sense to set the defaults to the host architecture in host-llvm, and always require explicit cross-compilation options. Note that that also means that in host-clang, we shouldn't set CLANG_DEFAULT_LINKER=$(TARGET_LD) - instead the linker should always be specified explicitly when cross-building. Regards, Arnout ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 2019-11-09 10:40 ` [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 Romain Naour 2019-11-09 12:01 ` Yann E. MORIN @ 2019-11-09 22:29 ` Peter Seiderer 1 sibling, 0 replies; 8+ messages in thread From: Peter Seiderer @ 2019-11-09 22:29 UTC (permalink / raw) To: buildroot Hello Romain, On Sat, 9 Nov 2019 11:40:54 +0100, Romain Naour <romain.naour@gmail.com> wrote: > Hi Yann, All, > > Le 07/11/2019 ? 08:16, Thomas Petazzoni a ?crit?: > > Hello, > > > > Recent build failures and runtime-tests failures > > ================================================ > > > > This is the list of Buildroot build failures that occurred on > > 2019-11-06, and for which you are a registered architecture developer, > > package developer or defconfig developer. This list also include > > runtime tests failures. Please help us improving the quality of > > Buildroot by investigating those build failures and sending patches to > > fix them. Thanks! > > > > Results for the 'master' branch > > ------------------------------- > > > > Build failures related to your packages: > > > > arch | reason | url > > -------------+--------------------------------+--------------------------------------------------------------------------------- > > mips64el | host-llvm-9.0.0 | http://autobuild.buildroot.net/results/d3aa03ca7085727d0794228178c7744859900137 > > This is weird since mips is not (yet) supported by Buildroot's llvm package (see > BR2_PACKAGE_LLVM_ARCH_SUPPORTS). > > host-llvm dependency seems trigged by another package at Makefile level without > being llvm/clang at Kconfig level. > > Yann, the issue seems related to qt5tools for Qt 5.12 [1]. > Since it now depends on libclang, BR2_PACKAGE_QT5TOOLS_QDOC_TOOL must depends on > BR2_PACKAGE_LLVM_ARCH_SUPPORTS (at least). > > [1] > https://git.buildroot.net/buildroot/commit/?id=57c1d3be4ecadd6802414a0943185c4ab6d82937 > > > arm | mesa3d-19.2.2 | http://autobuild.buildroot.net/results/891acd135b9d92067da83aee4c987e872137d07c > > gallium nouveau issue on ARM with uClibc and c++14: > > FAILED: src/gallium/drivers/nouveau/f590698@@nouveau at sta/codegen_nv50_ir_ra.cpp.o > > error: 'isinf' was not declared in this scope And can be fixed with (use c++ std:isinf instead of the plain c version): --- build/mesa3d-19.2.3/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp.orig2019-11-09 23:24:11.214532855 +0100 +++ build/mesa3d-19.2.3/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 2019-11-09 23:24:51.087263202 +0100 @@ -24,6 +24,7 @@ #include "codegen/nv50_ir_target.h" #include <algorithm> +#include <cmath> #include <stack> #include <limits> #if __cplusplus >= 201103L @@ -1347,7 +1348,7 @@ bestMaxReg = it->maxReg; } } - if (isinf(bestScore)) { + if (std::isinf(bestScore)) { ERROR("no viable spill candidates left\n"); return false; } Regards, Peter > > Best regards, > Romain > > > > > > > > > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-11-17 19:22 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <5dc3c4b8.1c69fb81.ff4f2.2a4cSMTPIN_ADDED_MISSING@mx.google.com> 2019-11-09 10:40 ` [Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06 Romain Naour 2019-11-09 12:01 ` Yann E. MORIN 2019-11-09 13:09 ` Romain Naour 2019-11-09 13:30 ` Thomas Petazzoni 2019-11-09 13:42 ` Romain Naour 2019-11-09 21:33 ` Yann E. MORIN 2019-11-17 19:22 ` Arnout Vandecappelle 2019-11-09 22:29 ` Peter Seiderer
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.