[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06

[Romain Naour]

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

> 
> 
> 

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06

[Romain Naour]

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

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06

[Thomas Petazzoni]

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

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06

[Romain Naour]

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
> 

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06

[Arnout Vandecappelle]

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

[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-11-06

[Peter Seiderer]

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