* [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 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
* [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
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.