* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-09 21:03 ` Thomas Petazzoni
@ 2019-05-09 21:19 ` Giulio Benetti
2019-05-11 21:00 ` Giulio Benetti
2019-05-09 21:41 ` LP C
` (3 subsequent siblings)
4 siblings, 1 reply; 15+ messages in thread
From: Giulio Benetti @ 2019-05-09 21:19 UTC (permalink / raw)
To: buildroot
Hello Thomas, All,
Il 09/05/2019 23:03, Thomas Petazzoni ha scritto:
> Hello,
>
> -rc1 has been released, let's try to resume my traditional effort of
> analyzing the build failures, and bring attention to some of them.
>
> Julien, Louis-Paul, Nylon, Romain, Vadim, Adam, Peter, Bernd, please
> see below: there are some questions for you! :-)
>
> On Thu, 09 May 2019 06:00:37 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
>> arm | atftp-0.7.2 | NOK | http://autobuild.buildroot.net/results/8606908b60fca430366d558a8e6db7a06ca08631 |
>> arc | atftp-0.7.2 | NOK | http://autobuild.buildroot.net/results/177a64fb419a6d4c2349970bce966819925e4de5 |
>
> These were download issues on my build server due to an old wget. They
> are fixed once the tarball is cached on sources.buildroot.net.
>
>> m68k | bullet-2.88 | NOK | http://autobuild.buildroot.net/results/e96cacd185f14479433f91ccd47d76058cf5b345 |
>
> Fixed by https://git.buildroot.org/buildroot/commit/?id=81fa9080c18d8f3f6278a874d1df2746f081ce5f.
>
>> sh4 | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/2fd595b1bd0be42b0e302cf4e6d958a64cb20244 |
>> i686 | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/b14a16e695ab38d2b30ff801b43dc44ece1efc71 |
>> i586 | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/b31cb312953065de9c8ac36c27aa3260b0872721 |
>> mipsel | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/695c9775d2fe69ef64b87d8196b097c5ba4995c4 |
>> xtensa | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/6cc427b80e8a9abb7850df0a782545fd552d6ee8 |
>
> I have submitted http://patchwork.ozlabs.org/patch/1097677/ to fix this.
>
>> arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/b72ded5e1fb56ca197386472f24d776a52954bac | ORPH
>> x86_64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/0ce9055a6db721b211639b2105ba2f1430b6f5a7 | ORPH
>> x86_64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/e92d094e401ffef33f26ba6d10cfbc830befbfe8 | ORPH
>> powerpc | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/27bb494c0cc6672a1f5578857d5e8b52a2d5f7be | ORPH
>> i586 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/7ed74b6183acc34dc5406a6801b01d05b38778d2 | ORPH
>> aarch64_be | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/4232294a3d0c2d52e01f590918c2873e987e876c | ORPH
>> arc | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/22357f7ec97d19b7bae58dc65c172bd8f49e0e70 | ORPH
>> x86_64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/44c93bc8a9d982a55bdb747cfc5b084881b3b86a | ORPH
>> arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/4bf68114d8fb6c7b10558f08eff17a2d6cc74156 | ORPH
>> riscv32 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/7d57931d110011ce9ca5c2cb2192e5ce3e4a37f9 | ORPH
>> arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/02241fe5e6585fdb922557df65141dce47aec99d | ORPH
>> powerpc64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/befa1070dffc928ce5a56b392ca0f5ecce3d28b7 | ORPH
>> arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/6006a70a00e48745c0de372187f1bef28d70de3f | ORPH
>> arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/cb0ca725aa66d661cfe63168432c626f663f4d44 | ORPH
>> powerpc | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/bebccc77513aafe07a1e3ee80a36c082ff1b7256 | ORPH
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=9798ea7cfb8a5d222e5939860ba3adcf0292126b.
>
>> xtensa | host-libsodium | TIM | http://autobuild.buildroot.net/results/4f460ff42739e3c8277baf50880139aefd169cfa |
>
> We still have this regular timeout, almost always on Julien Boibessot's
> machine. Julien, do you have any idea what's going on ?
>
>> x86_64 | intel-mediadriver-18.4.0 | NOK | http://autobuild.buildroot.net/results/c4725517fbca4d113a09935c90f6389e85743c08 |
>
> Louis-Paul, you added this package, it seems to fail building with the
> musl C library. Could you have a look ?
>
>> nds32le | keepalived-2.0.15 | NOK | http://autobuild.buildroot.net/results/85af2b037f2b3277a572302acf113c9e11d0223b |
>
> ../lib/liblib.a(parser.o): in function `read_double_func':
> parser.c:(.text+0x734): undefined reference to `__fpclassify'
>
> This feels like a toolchain issue. Nylon, could you have a look ?
>
>> m68k | libtorrent-rasterbar-1.2.1 | NOK | http://autobuild.buildroot.net/results/98008526d4b269140dae2462acb77478c79e3ca0 |
>
> disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::abort(bool)':
> disk_io_thread.cpp:315:2: internal compiler error: in connect_traces, at dwarf2cfi.c:2802
>
> Romain, you are familiar with many of the compiler bugs that we have on
> weird architectures. Does this one ring any bell ?
>
>> microblazeel | lynx-2.8.9rel.1 | NOK | http://autobuild.buildroot.net/results/23a421e15c32b17ff2f69f183a2e8620ecb93316 |
>
> libiconv issue. According to
> http://autobuild.buildroot.net/?reason=lynx% it only happens once in a
> while. Vadim, you looked at a lot of libiconv/libintl issues, perhaps
> you will have an idea ?
>
>> powerpc64 | netsurf | TIM | http://autobuild.buildroot.net/results/eeb2863c6237aac8428e49a5ee514d43088b0fb8 |
>> x86_64 | netsurf | TIM | http://autobuild.buildroot.net/results/f938fd1515f1d6e11b57aa6e314135789da52a44 |
>> arm | netsurf-3.8 | NOK | http://autobuild.buildroot.net/results/ca4f61a4aba114b04fcf12f66b6266f78807aab8 |
>> m68k | netsurf-3.8 | NOK | http://autobuild.buildroot.net/results/e48416d9ee659dbe9ee3115c4005b2587f08fbe0 |
>
> I submitted
> http://patchwork.ozlabs.org/project/buildroot/list/?series=107046 to
> fix both the timeouts and build failures, even though the fixes are
> quite fragile...
>
>> sparc64 | openjdk-jdk-12+33 | NOK | http://autobuild.buildroot.net/results/47b604d67556087289461d54f6b54f67a41d4b09 |
>
> Some java.nio.file.NoSuchFileException. Adam, it seems to only occur on
> sparc64. Could you confirm that ? If it's the case, perhaps we should
> simply drop sparc64 support in openjdk ?
>
>> aarch64 | python-numpy-1.16.3 | NOK | http://autobuild.buildroot.net/results/50f7f09a9f830cd7b94f8fc83c09fc3d39297d3d |
>
> /home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lcblas -o /tmp/tmph865w02v/a.out
> /home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scnrm2_'
> /home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scasum_'
> collect2: error: ld returned 1 exit status
> /home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lblas -o /tmp/tmph865w02v/a.out
> /tmp/tmph865w02v/tmp/tmph865w02v/source.o: In function `main':
> /tmp/tmph865w02v/source.c:6: undefined reference to `cblas_ddot'
> collect2: error: ld returned 1 exit status
>
> I'm not sure what's going on here. Sadly, Samuel who was maintaining
> python-numpy, is no longer active in Buildroot. Is there anyone else
> volunteering to have a look ?
I can try to work this out.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
>> x86_64 | qt5base-5.12.2 | NOK | http://autobuild.buildroot.net/results/d3fa9fa6d897ac120e716d2e114e0706ac62fae7 |
>
> global/qfloat16_f16c.c:57:6: error: redefinition of 'void qFloatToFloat16_fast(quint16*, const float*, qsizetype)'
> void qFloatToFloat16_fast(quint16 *out, const float *in, qsizetype len) Q_DECL_NOTHROW
> ^~~~~~~~~~~~~~~~~~~~
>
> Peter (Seiderer), any idea ?
>
>> powerpc | qt5multimedia-5.12.2 | NOK | http://autobuild.buildroot.net/results/11790cad7dab795d50b53d44750c838a86039d1f |
>
> qgstreamerplayersession.cpp:400:44: error: cannot convert 'GValue* {aka _GValue*}' to 'void**' for argument '2' to 'GstIteratorResult gst_iterator_next(GstIterator*, void**)'
> while (gst_iterator_next (it, &data) == GST_ITERATOR_OK) {
>
> GStreamer/Qt compatibility issue. Peter (Seiderer), again ? :-)
>
>> mips64el | samba4-4.9.7 | NOK | http://autobuild.buildroot.net/results/28b9caf2e03ff79e32220c7289d34bb8c303abdf |
>
> /home/peko/autobuild/instance-0/output/host/mips64el-buildroot-linux-uclibc/sysroot/usr/include/stdint.h:122:27: error: conflicting types for 'uintptr_t'
> typedef unsigned long int uintptr_t;
> ^
> In file included from ../source3/registry/tests/test_regfio.c:23:0:
> ../third_party/cmocka/cmocka.h:126:28: note: previous declaration of 'uintptr_t' was here
> typedef unsigned int uintptr_t;
>
> Bernd, you are taking care of Samba, could you have a look ?
>
>> i686 | spandsp-20180108 | NOK | http://autobuild.buildroot.net/results/b04da43e67b246cf3c4b2805b8cf6cf0c90197a9 |
>
> gsm0610_rpe.c:132:5: error: invalid 'asm': invalid constraints for operand
> __asm__ __volatile__(
> ^~~~~~~
>
> Bernd, spandsp is also one of your packages, could you have a look ?
>
>> m68k | strace-5.0 | NOK | http://autobuild.buildroot.net/results/c036b11bf1f2fc39f42661634ef3e03360fb85de |
>
> Baruch is proposing http://patchwork.ozlabs.org/patch/1097490/ to avoid
> this build issue.
>
>> powerpc | suricata-4.1.3 | NOK | http://autobuild.buildroot.net/results/d9e53484b6114a6b6271eb1c40c32ddc9fec6fb3 |
>
> This should be fixed by http://patchwork.ozlabs.org/project/buildroot/list/?series=104482.
>
>> aarch64 | vdr-plugin-vnsiserver-v1.8.0 | NOK | http://autobuild.buildroot.net/results/355a4314aa8f36631119841b83f15abe3f8e14ce |
>
> I need to revive an old patch from Fabrice to fix this one.
>
>> powerpc | wireshark-3.0.1 | NOK | http://autobuild.buildroot.net/results/09464861add139bd4048398029f54d75539385b8 | ORPH
>
> Toolchain issue ? Romain, any idea ?
>
> Thomas
>
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-09 21:19 ` Giulio Benetti
@ 2019-05-11 21:00 ` Giulio Benetti
2019-05-14 20:36 ` Yann E. MORIN
0 siblings, 1 reply; 15+ messages in thread
From: Giulio Benetti @ 2019-05-11 21:00 UTC (permalink / raw)
To: buildroot
Hello Yann, All,
Il 09/05/2019 23:19, Giulio Benetti ha scritto:
>>> aarch64 | python-numpy-1.16.3 | NOK | http://autobuild.buildroot.net/results/50f7f09a9f830cd7b94f8fc83c09fc3d39297d3d |
>>
>> /home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lcblas -o /tmp/tmph865w02v/a.out
>> /home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scnrm2_'
>> /home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scasum_'
>> collect2: error: ld returned 1 exit status
>> /home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lblas -o /tmp/tmph865w02v/a.out
>> /tmp/tmph865w02v/tmp/tmph865w02v/source.o: In function `main':
>> /tmp/tmph865w02v/source.c:6: undefined reference to `cblas_ddot'
>> collect2: error: ld returned 1 exit status
>>
>> I'm not sure what's going on here. Sadly, Samuel who was maintaining
>> python-numpy, is no longer active in Buildroot. Is there anyone else
>> volunteering to have a look ?
>
> I can try to work this out.
>
As spoken in IRC this builds correctly with every Docker in Adam Duskett:
https://github.com/aduskett/buildroot-docker-devel
included Ubuntu 14.04(Trusty), the same as Yann's Autobuilder.
I'm waiting for Yann to report if it works for him too or not.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-11 21:00 ` Giulio Benetti
@ 2019-05-14 20:36 ` Yann E. MORIN
2019-05-14 21:47 ` Giulio Benetti
0 siblings, 1 reply; 15+ messages in thread
From: Yann E. MORIN @ 2019-05-14 20:36 UTC (permalink / raw)
To: buildroot
Giulio, All,
On 2019-05-11 23:00 +0200, Giulio Benetti spake thusly:
> Hello Yann, All,
>
> Il 09/05/2019 23:19, Giulio Benetti ha scritto:
> >>> aarch64 | python-numpy-1.16.3 | NOK | http://autobuild.buildroot.net/results/50f7f09a9f830cd7b94f8fc83c09fc3d39297d3d |
> >>
> >>/home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lcblas -o /tmp/tmph865w02v/a.out
> >>/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scnrm2_'
> >>/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scasum_'
> >>collect2: error: ld returned 1 exit status
> >>/home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lblas -o /tmp/tmph865w02v/a.out
> >>/tmp/tmph865w02v/tmp/tmph865w02v/source.o: In function `main':
> >>/tmp/tmph865w02v/source.c:6: undefined reference to `cblas_ddot'
> >>collect2: error: ld returned 1 exit status
> >>
> >>I'm not sure what's going on here. Sadly, Samuel who was maintaining
> >>python-numpy, is no longer active in Buildroot. Is there anyone else
> >>volunteering to have a look ?
> >
> >I can try to work this out.
> >
>
> As spoken in IRC this builds correctly with every Docker in Adam Duskett:
> https://github.com/aduskett/buildroot-docker-devel
>
> included Ubuntu 14.04(Trusty), the same as Yann's Autobuilder.
>
> I'm waiting for Yann to report if it works for him too or not.
Here is a quick summary of Giulio's and my findings:
Usign the configuration from the failed autobuild job:
- make clean; make python-numpy --> builds OK
- make clean; make --> fails to build
The root cause is a hidden dependency on lapack. When lapack is build
before python-numpy (which is highly possible, because of alphabetical
ordering), then python-numpy detects it and fails to build properly in
this case.
So, I can see two solutions:
- add an explicit, conditional dependency on lapack, and fix the
build,
- explicitly tell python-numpy to never use lapack.
Obviously, the first would be preferred, but it's probably non-trivial.
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] 15+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-14 20:36 ` Yann E. MORIN
@ 2019-05-14 21:47 ` Giulio Benetti
0 siblings, 0 replies; 15+ messages in thread
From: Giulio Benetti @ 2019-05-14 21:47 UTC (permalink / raw)
To: buildroot
Hi Yann,
Il 14/05/2019 22:36, Yann E. MORIN ha scritto:
> Giulio, All,
>
> On 2019-05-11 23:00 +0200, Giulio Benetti spake thusly:
>> Hello Yann, All,
>>
>> Il 09/05/2019 23:19, Giulio Benetti ha scritto:
>>>>> aarch64 | python-numpy-1.16.3 | NOK | http://autobuild.buildroot.net/results/50f7f09a9f830cd7b94f8fc83c09fc3d39297d3d |
>>>>
>>>> /home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lcblas -o /tmp/tmph865w02v/a.out
>>>> /home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scnrm2_'
>>>> /home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scasum_'
>>>> collect2: error: ld returned 1 exit status
>>>> /home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lblas -o /tmp/tmph865w02v/a.out
>>>> /tmp/tmph865w02v/tmp/tmph865w02v/source.o: In function `main':
>>>> /tmp/tmph865w02v/source.c:6: undefined reference to `cblas_ddot'
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> I'm not sure what's going on here. Sadly, Samuel who was maintaining
>>>> python-numpy, is no longer active in Buildroot. Is there anyone else
>>>> volunteering to have a look ?
>>>
>>> I can try to work this out.
>>>
>>
>> As spoken in IRC this builds correctly with every Docker in Adam Duskett:
>> https://github.com/aduskett/buildroot-docker-devel
>>
>> included Ubuntu 14.04(Trusty), the same as Yann's Autobuilder.
>>
>> I'm waiting for Yann to report if it works for him too or not.
>
> Here is a quick summary of Giulio's and my findings:
>
> Usign the configuration from the failed autobuild job:
>
> - make clean; make python-numpy --> builds OK
>
> - make clean; make --> fails to build
>
> The root cause is a hidden dependency on lapack. When lapack is build
> before python-numpy (which is highly possible, because of alphabetical
> ordering), then python-numpy detects it and fails to build properly in
> this case.
>
> So, I can see two solutions:
>
> - add an explicit, conditional dependency on lapack, and fix the
> build,
>
> - explicitly tell python-numpy to never use lapack.
>
> Obviously, the first would be preferred, but it's probably non-trivial.
I would go for the first one, but before I need to solve microblaze
toolchain bug 85180 impact.
It depends on expected time.
I'd hope to fix both for this week, but I can't assure.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
> Regards,
> Yann E. MORIN.
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-09 21:03 ` Thomas Petazzoni
2019-05-09 21:19 ` Giulio Benetti
@ 2019-05-09 21:41 ` LP C
2019-05-10 8:59 ` Vadym Kochan
` (2 subsequent siblings)
4 siblings, 0 replies; 15+ messages in thread
From: LP C @ 2019-05-09 21:41 UTC (permalink / raw)
To: buildroot
Hi all,
I'm crowding under the snow for few weeks, hope I will be able to dig into intel-mediadriver issue next week. But does not seem to be a big deal though!
Cheers,
On May 9 2019, at 11:03 pm, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> -rc1 has been released, let's try to resume my traditional effort of
> analyzing the build failures, and bring attention to some of them.
>
> Julien, Louis-Paul, Nylon, Romain, Vadim, Adam, Peter, Bernd, please
> see below: there are some questions for you! :-)
>
> On Thu, 09 May 2019 06:00:37 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
> > arm | atftp-0.7.2 | NOK | http://autobuild.buildroot.net/results/8606908b60fca430366d558a8e6db7a06ca08631 |
> > arc | atftp-0.7.2 | NOK | http://autobuild.buildroot.net/results/177a64fb419a6d4c2349970bce966819925e4de5 |
>
>
> These were download issues on my build server due to an old wget. They
> are fixed once the tarball is cached on sources.buildroot.net.
>
> > m68k | bullet-2.88 | NOK | http://autobuild.buildroot.net/results/e96cacd185f14479433f91ccd47d76058cf5b345 |
> Fixed by https://git.buildroot.org/buildroot/commit/?id=81fa9080c18d8f3f6278a874d1df2746f081ce5f.
> > sh4 | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/2fd595b1bd0be42b0e302cf4e6d958a64cb20244 |
> > i686 | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/b14a16e695ab38d2b30ff801b43dc44ece1efc71 |
> > i586 | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/b31cb312953065de9c8ac36c27aa3260b0872721 |
> > mipsel | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/695c9775d2fe69ef64b87d8196b097c5ba4995c4 |
> > xtensa | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/6cc427b80e8a9abb7850df0a782545fd552d6ee8 |
>
>
> I have submitted http://patchwork.ozlabs.org/patch/1097677/ to fix this.
> > arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/b72ded5e1fb56ca197386472f24d776a52954bac | ORPH
> > x86_64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/0ce9055a6db721b211639b2105ba2f1430b6f5a7 | ORPH
> > x86_64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/e92d094e401ffef33f26ba6d10cfbc830befbfe8 | ORPH
> > powerpc | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/27bb494c0cc6672a1f5578857d5e8b52a2d5f7be | ORPH
> > i586 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/7ed74b6183acc34dc5406a6801b01d05b38778d2 | ORPH
> > aarch64_be | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/4232294a3d0c2d52e01f590918c2873e987e876c | ORPH
> > arc | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/22357f7ec97d19b7bae58dc65c172bd8f49e0e70 | ORPH
> > x86_64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/44c93bc8a9d982a55bdb747cfc5b084881b3b86a | ORPH
> > arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/4bf68114d8fb6c7b10558f08eff17a2d6cc74156 | ORPH
> > riscv32 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/7d57931d110011ce9ca5c2cb2192e5ce3e4a37f9 | ORPH
> > arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/02241fe5e6585fdb922557df65141dce47aec99d | ORPH
> > powerpc64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/befa1070dffc928ce5a56b392ca0f5ecce3d28b7 | ORPH
> > arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/6006a70a00e48745c0de372187f1bef28d70de3f | ORPH
> > arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/cb0ca725aa66d661cfe63168432c626f663f4d44 | ORPH
> > powerpc | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/bebccc77513aafe07a1e3ee80a36c082ff1b7256 | ORPH
>
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=9798ea7cfb8a5d222e5939860ba3adcf0292126b.
>
> > xtensa | host-libsodium | TIM | http://autobuild.buildroot.net/results/4f460ff42739e3c8277baf50880139aefd169cfa |
> We still have this regular timeout, almost always on Julien Boibessot's
> machine. Julien, do you have any idea what's going on ?
>
> > x86_64 | intel-mediadriver-18.4.0 | NOK | http://autobuild.buildroot.net/results/c4725517fbca4d113a09935c90f6389e85743c08 |
> Louis-Paul, you added this package, it seems to fail building with the
> musl C library. Could you have a look ?
>
> > nds32le | keepalived-2.0.15 | NOK | http://autobuild.buildroot.net/results/85af2b037f2b3277a572302acf113c9e11d0223b |
> ../lib/liblib.a(parser.o): in function `read_double_func':
> parser.c:(.text+0x734): undefined reference to `__fpclassify'
>
> This feels like a toolchain issue. Nylon, could you have a look ?
> > m68k | libtorrent-rasterbar-1.2.1 | NOK | http://autobuild.buildroot.net/results/98008526d4b269140dae2462acb77478c79e3ca0 |
> disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::abort(bool)':
> disk_io_thread.cpp:315:2: internal compiler error: in connect_traces, at dwarf2cfi.c:2802
>
> Romain, you are familiar with many of the compiler bugs that we have on
> weird architectures. Does this one ring any bell ?
>
> > microblazeel | lynx-2.8.9rel.1 | NOK | http://autobuild.buildroot.net/results/23a421e15c32b17ff2f69f183a2e8620ecb93316 |
> libiconv issue. According to
> http://autobuild.buildroot.net/?reason=lynx% it only happens once in a
> while. Vadim, you looked at a lot of libiconv/libintl issues, perhaps
> you will have an idea ?
>
> > powerpc64 | netsurf | TIM | http://autobuild.buildroot.net/results/eeb2863c6237aac8428e49a5ee514d43088b0fb8 |
> > x86_64 | netsurf | TIM | http://autobuild.buildroot.net/results/f938fd1515f1d6e11b57aa6e314135789da52a44 |
> > arm | netsurf-3.8 | NOK | http://autobuild.buildroot.net/results/ca4f61a4aba114b04fcf12f66b6266f78807aab8 |
> > m68k | netsurf-3.8 | NOK | http://autobuild.buildroot.net/results/e48416d9ee659dbe9ee3115c4005b2587f08fbe0 |
>
>
> I submitted
> http://patchwork.ozlabs.org/project/buildroot/list/?series=107046 to
> fix both the timeouts and build failures, even though the fixes are
> quite fragile...
>
> > sparc64 | openjdk-jdk-12+33 | NOK | http://autobuild.buildroot.net/results/47b604d67556087289461d54f6b54f67a41d4b09 |
> Some java.nio.file.NoSuchFileException. Adam, it seems to only occur on
> sparc64. Could you confirm that ? If it's the case, perhaps we should
> simply drop sparc64 support in openjdk ?
>
> > aarch64 | python-numpy-1.16.3 | NOK | http://autobuild.buildroot.net/results/50f7f09a9f830cd7b94f8fc83c09fc3d39297d3d |
> /home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lcblas -o /tmp/tmph865w02v/a.out
> /home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scnrm2_'
> /home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scasum_'
> collect2: error: ld returned 1 exit status
> /home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lblas -o /tmp/tmph865w02v/a.out
> /tmp/tmph865w02v/tmp/tmph865w02v/source.o: In function `main':
> /tmp/tmph865w02v/source.c:6: undefined reference to `cblas_ddot'
> collect2: error: ld returned 1 exit status
>
> I'm not sure what's going on here. Sadly, Samuel who was maintaining
> python-numpy, is no longer active in Buildroot. Is there anyone else
> volunteering to have a look ?
>
> > x86_64 | qt5base-5.12.2 | NOK | http://autobuild.buildroot.net/results/d3fa9fa6d897ac120e716d2e114e0706ac62fae7 |
> global/qfloat16_f16c.c:57:6: error: redefinition of 'void qFloatToFloat16_fast(quint16*, const float*, qsizetype)'
> void qFloatToFloat16_fast(quint16 *out, const float *in, qsizetype len) Q_DECL_NOTHROW
> ^~~~~~~~~~~~~~~~~~~~
>
> Peter (Seiderer), any idea ?
> > powerpc | qt5multimedia-5.12.2 | NOK | http://autobuild.buildroot.net/results/11790cad7dab795d50b53d44750c838a86039d1f |
> qgstreamerplayersession.cpp:400:44: error: cannot convert 'GValue* {aka _GValue*}' to 'void**' for argument '2' to 'GstIteratorResult gst_iterator_next(GstIterator*, void**)'
> while (gst_iterator_next (it, &data) == GST_ITERATOR_OK) {
>
> GStreamer/Qt compatibility issue. Peter (Seiderer), again ? :-)
> > mips64el | samba4-4.9.7 | NOK | http://autobuild.buildroot.net/results/28b9caf2e03ff79e32220c7289d34bb8c303abdf |
> /home/peko/autobuild/instance-0/output/host/mips64el-buildroot-linux-uclibc/sysroot/usr/include/stdint.h:122:27: error: conflicting types for 'uintptr_t'
> typedef unsigned long int uintptr_t;
> ^
> In file included from ../source3/registry/tests/test_regfio.c:23:0:
> ../third_party/cmocka/cmocka.h:126:28: note: previous declaration of 'uintptr_t' was here
> typedef unsigned int uintptr_t;
>
> Bernd, you are taking care of Samba, could you have a look ?
> > i686 | spandsp-20180108 | NOK | http://autobuild.buildroot.net/results/b04da43e67b246cf3c4b2805b8cf6cf0c90197a9 |
> gsm0610_rpe.c:132:5: error: invalid 'asm': invalid constraints for operand
> __asm__ __volatile__(
> ^~~~~~~
>
> Bernd, spandsp is also one of your packages, could you have a look ?
> > m68k | strace-5.0 | NOK | http://autobuild.buildroot.net/results/c036b11bf1f2fc39f42661634ef3e03360fb85de |
> Baruch is proposing http://patchwork.ozlabs.org/patch/1097490/ to avoid
> this build issue.
>
> > powerpc | suricata-4.1.3 | NOK | http://autobuild.buildroot.net/results/d9e53484b6114a6b6271eb1c40c32ddc9fec6fb3 |
> This should be fixed by http://patchwork.ozlabs.org/project/buildroot/list/?series=104482.
> > aarch64 | vdr-plugin-vnsiserver-v1.8.0 | NOK | http://autobuild.buildroot.net/results/355a4314aa8f36631119841b83f15abe3f8e14ce |
> I need to revive an old patch from Fabrice to fix this one.
> > powerpc | wireshark-3.0.1 | NOK | http://autobuild.buildroot.net/results/09464861add139bd4048398029f54d75539385b8 | ORPH
> Toolchain issue ? Romain, any idea ?
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190509/1a0d4353/attachment-0001.html>
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-09 21:03 ` Thomas Petazzoni
2019-05-09 21:19 ` Giulio Benetti
2019-05-09 21:41 ` LP C
@ 2019-05-10 8:59 ` Vadym Kochan
2019-05-13 11:20 ` Julien Boibessot
2019-05-23 7:07 ` Nylon Chen
4 siblings, 0 replies; 15+ messages in thread
From: Vadym Kochan @ 2019-05-10 8:59 UTC (permalink / raw)
To: buildroot
Hi Thomas, All
On Thu, May 09, 2019 at 11:03:24PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> -rc1 has been released, let's try to resume my traditional effort of
> analyzing the build failures, and bring attention to some of them.
>
> Julien, Louis-Paul, Nylon, Romain, Vadim, Adam, Peter, Bernd, please
> see below: there are some questions for you! :-)
>
[SNIP]
>
> > microblazeel | lynx-2.8.9rel.1 | NOK | http://autobuild.buildroot.net/results/23a421e15c32b17ff2f69f183a2e8620ecb93316 |
>
> libiconv issue. According to
> http://autobuild.buildroot.net/?reason=lynx% it only happens once in a
> while. Vadim, you looked at a lot of libiconv/libintl issues, perhaps
> you will have an idea ?
I will try to fix it.
[SNIP]
Regards,
Vadim Kochan
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-09 21:03 ` Thomas Petazzoni
` (2 preceding siblings ...)
2019-05-10 8:59 ` Vadym Kochan
@ 2019-05-13 11:20 ` Julien Boibessot
2019-05-13 11:31 ` Thomas Petazzoni
2019-05-23 7:07 ` Nylon Chen
4 siblings, 1 reply; 15+ messages in thread
From: Julien Boibessot @ 2019-05-13 11:20 UTC (permalink / raw)
To: buildroot
Hello,
Thomas,
On 09/05/2019 23:03, Thomas Petazzoni wrote:
> Hello,
>
> -rc1 has been released, let's try to resume my traditional effort of
> analyzing the build failures, and bring attention to some of them.
>
> Julien, Louis-Paul, Nylon, Romain, Vadim, Adam, Peter, Bernd, please
> see below: there are some questions for you! :-)
>
... cut ...
>
>> xtensa | host-libsodium | TIM | http://autobuild.buildroot.net/results/4f460ff42739e3c8277baf50880139aefd169cfa |
> We still have this regular timeout, almost always on Julien Boibessot's
> machine. Julien, do you have any idea what's going on ?
I have already brought this problem up a few times before but no one has
a clue.
My build system is consuming 100% CPU in conftest process when building
libsodium.
In this state I have to manually kill all conftest processes otherwise
the build is blocked for days... :-)
Best regards,
Julien
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-13 11:20 ` Julien Boibessot
@ 2019-05-13 11:31 ` Thomas Petazzoni
2019-05-13 15:59 ` Julien Boibessot
0 siblings, 1 reply; 15+ messages in thread
From: Thomas Petazzoni @ 2019-05-13 11:31 UTC (permalink / raw)
To: buildroot
Hello,
On Mon, 13 May 2019 13:20:54 +0200
Julien Boibessot <julien.boibessot@free.fr> wrote:
> I have already brought this problem up a few times before but no one has
> a clue.
> My build system is consuming 100% CPU in conftest process when building
> libsodium.
>
> In this state I have to manually kill all conftest processes otherwise
> the build is blocked for days... :-)
Which configure test is it running when it's blocked ? What does
"strace" says about this conftest process that is stuck ?
Can you reproduce manually ? Does it happen every time libsodium is
built on your machine, or only once in a while ?
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-13 11:31 ` Thomas Petazzoni
@ 2019-05-13 15:59 ` Julien Boibessot
2019-05-25 15:31 ` Arnout Vandecappelle
0 siblings, 1 reply; 15+ messages in thread
From: Julien Boibessot @ 2019-05-13 15:59 UTC (permalink / raw)
To: buildroot
Thomas,
On 13/05/2019 13:31, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 13 May 2019 13:20:54 +0200
> Julien Boibessot <julien.boibessot@free.fr> wrote:
>
>> I have already brought this problem up a few times before but no one has
>> a clue.
>> My build system is consuming 100% CPU in conftest process when building
>> libsodium.
>>
>> In this state I have to manually kill all conftest processes otherwise
>> the build is blocked for days... :-)
> Which configure test is it running when it's blocked ?
when host-libsodium fails I would say it is blocked on:
/checking whether segmentation violations can be caught when using
the C compiler.../
> What does
> "strace" says about this conftest process that is stuck ?
>
> Can you reproduce manually ? Does it happen every time libsodium is
> built on your machine, or only once in a while ?
It sometimes can be reproduced manually but not as often as from BR
build system.
I would say when it fails from BR build, I can kill it and reproduce the
problem once.
Most of the time it works well when build manually.
Best regards,
Julien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190513/d9ebed49/attachment.html>
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-13 15:59 ` Julien Boibessot
@ 2019-05-25 15:31 ` Arnout Vandecappelle
2019-05-26 14:08 ` LP C
0 siblings, 1 reply; 15+ messages in thread
From: Arnout Vandecappelle @ 2019-05-25 15:31 UTC (permalink / raw)
To: buildroot
On 13/05/2019 17:59, Julien Boibessot wrote:
> Thomas,
>
> On 13/05/2019 13:31, Thomas Petazzoni wrote:
>> Hello,
>>
>> On Mon, 13 May 2019 13:20:54 +0200
>> Julien Boibessot <julien.boibessot@free.fr> wrote:
>>
>>> I have already brought this problem up a few times before but no one has
>>> a clue.
>>> My build system is consuming 100% CPU in conftest process when building
>>> libsodium.
>>>
>>> In this state I have to manually kill all conftest processes otherwise
>>> the build is blocked for days... :-)
>> Which configure test is it running when it's blocked ?
>
> when host-libsodium fails I would say it is blocked on:
>
> ??? /checking whether segmentation violations can be caught when using the C
> compiler.../
I've taken a look at the code of that test. There's nothing really wrong with
it, but it's pretty much undefined behaviour so the compiler is free to do
stupid things.
Fortunately, we know that SIGSEGV can be caught since we know we're building on
Linux, and anyway we don't care a lot for host-libsodium. So we can just set the
cache variable ax_cv_check_cCATCHABLE_SEGV=yes.
Regards,
Arnout
>
>
>> What does
>> "strace" says about this conftest process that is stuck ?
>>
>> Can you reproduce manually ? Does it happen every time libsodium is
>> built on your machine, or only once in a while ?
>
> It sometimes can be reproduced manually but not as often as from BR build system.
> I would say when it fails from BR build, I can kill it and reproduce the problem
> once.
>
> Most of the time it works well when build manually.
>
> Best regards,
> Julien
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-25 15:31 ` Arnout Vandecappelle
@ 2019-05-26 14:08 ` LP C
2019-05-26 18:36 ` Thomas Petazzoni
0 siblings, 1 reply; 15+ messages in thread
From: LP C @ 2019-05-26 14:08 UTC (permalink / raw)
To: buildroot
On May 25 2019, at 5:31 pm, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
> On 13/05/2019 17:59, Julien Boibessot wrote:
> > Thomas,
> >
> > On 13/05/2019 13:31, Thomas Petazzoni wrote:
> > > Hello,
> > >
> > > On Mon, 13 May 2019 13:20:54 +0200
> > > Julien Boibessot <julien.boibessot@free.fr> wrote:
> > >
> > > > I have already brought this problem up a few times before but no one has
> > > > a clue.
> > > > My build system is consuming 100% CPU in conftest process when building
> > > > libsodium.
> > > >
> > > > In this state I have to manually kill all conftest processes otherwise
> > > > the build is blocked for days... :-)
> > >
> > > Which configure test is it running when it's blocked ?
> >
> >
> > when host-libsodium fails I would say it is blocked on:
> > /checking whether segmentation violations can be caught when using the C
> > compiler.../
>
>
> I've taken a look at the code of that test. There's nothing really wrong with
> it, but it's pretty much undefined behaviour so the compiler is free to do
> stupid things.
>
> Fortunately, we know that SIGSEGV can be caught since we know we're building on
> Linux, and anyway we don't care a lot for host-libsodium. So we can just set the
> cache variable ax_cv_check_cCATCHABLE_SEGV=yes.
>
> Regards,
> Arnout
>
> >
> >
> > > What does
> > > "strace" says about this conftest process that is stuck ?
> > >
> > > Can you reproduce manually ? Does it happen every time libsodium is
> > > built on your machine, or only once in a while ?
> >
> >
> > It sometimes can be reproduced manually but not as often as from BR build system.
> > I would say when it fails from BR build, I can kill it and reproduce the problem
> > once.
> >
> > Most of the time it works well when build manually.
> > Best regards,
> > Julien
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
Hi Thomas,
https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/recipes-multimedia/libva/intel-media-driver/0001-linux-fix-build-when-using-musl.patch
seems to fix the issue with musl. This patch does not break the build with standard libc. As it is a patch from yocto, can I use it directly or is there any license restriction to do so?
Thanks,
LP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190526/1e3ffd0e/attachment.html>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2019-05-08
2019-05-09 21:03 ` Thomas Petazzoni
` (3 preceding siblings ...)
2019-05-13 11:20 ` Julien Boibessot
@ 2019-05-23 7:07 ` Nylon Chen
4 siblings, 0 replies; 15+ messages in thread
From: Nylon Chen @ 2019-05-23 7:07 UTC (permalink / raw)
To: buildroot
Hello, Thomas, all
sorry I miss this message.
On Fri, May 10, 2019 at 05:03:24AM +0800, Thomas Petazzoni wrote:
> Hello,
>
> -rc1 has been released, let's try to resume my traditional effort of
> analyzing the build failures, and bring attention to some of them.
>
> Julien, Louis-Paul, Nylon, Romain, Vadim, Adam, Peter, Bernd, please
> see below: there are some questions for you! :-)
>
> On Thu, 09 May 2019 06:00:37 -0000
> Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
>
> > arm | atftp-0.7.2 | NOK | http://autobuild.buildroot.net/results/8606908b60fca430366d558a8e6db7a06ca08631 |
> > arc | atftp-0.7.2 | NOK | http://autobuild.buildroot.net/results/177a64fb419a6d4c2349970bce966819925e4de5 |
>
> These were download issues on my build server due to an old wget. They
> are fixed once the tarball is cached on sources.buildroot.net.
>
> > m68k | bullet-2.88 | NOK | http://autobuild.buildroot.net/results/e96cacd185f14479433f91ccd47d76058cf5b345 |
>
> Fixed by https://git.buildroot.org/buildroot/commit/?id=81fa9080c18d8f3f6278a874d1df2746f081ce5f.
>
> > sh4 | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/2fd595b1bd0be42b0e302cf4e6d958a64cb20244 |
> > i686 | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/b14a16e695ab38d2b30ff801b43dc44ece1efc71 |
> > i586 | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/b31cb312953065de9c8ac36c27aa3260b0872721 |
> > mipsel | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/695c9775d2fe69ef64b87d8196b097c5ba4995c4 |
> > xtensa | cracklib-2.9.7 | NOK | http://autobuild.buildroot.net/results/6cc427b80e8a9abb7850df0a782545fd552d6ee8 |
>
> I have submitted http://patchwork.ozlabs.org/patch/1097677/ to fix this.
>
> > arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/b72ded5e1fb56ca197386472f24d776a52954bac | ORPH
> > x86_64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/0ce9055a6db721b211639b2105ba2f1430b6f5a7 | ORPH
> > x86_64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/e92d094e401ffef33f26ba6d10cfbc830befbfe8 | ORPH
> > powerpc | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/27bb494c0cc6672a1f5578857d5e8b52a2d5f7be | ORPH
> > i586 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/7ed74b6183acc34dc5406a6801b01d05b38778d2 | ORPH
> > aarch64_be | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/4232294a3d0c2d52e01f590918c2873e987e876c | ORPH
> > arc | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/22357f7ec97d19b7bae58dc65c172bd8f49e0e70 | ORPH
> > x86_64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/44c93bc8a9d982a55bdb747cfc5b084881b3b86a | ORPH
> > arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/4bf68114d8fb6c7b10558f08eff17a2d6cc74156 | ORPH
> > riscv32 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/7d57931d110011ce9ca5c2cb2192e5ce3e4a37f9 | ORPH
> > arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/02241fe5e6585fdb922557df65141dce47aec99d | ORPH
> > powerpc64 | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/befa1070dffc928ce5a56b392ca0f5ecce3d28b7 | ORPH
> > arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/6006a70a00e48745c0de372187f1bef28d70de3f | ORPH
> > arm | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/cb0ca725aa66d661cfe63168432c626f663f4d44 | ORPH
> > powerpc | dhcp-4.4.1 | NOK | http://autobuild.buildroot.net/results/bebccc77513aafe07a1e3ee80a36c082ff1b7256 | ORPH
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=9798ea7cfb8a5d222e5939860ba3adcf0292126b.
>
> > xtensa | host-libsodium | TIM | http://autobuild.buildroot.net/results/4f460ff42739e3c8277baf50880139aefd169cfa |
>
> We still have this regular timeout, almost always on Julien Boibessot's
> machine. Julien, do you have any idea what's going on ?
>
> > x86_64 | intel-mediadriver-18.4.0 | NOK | http://autobuild.buildroot.net/results/c4725517fbca4d113a09935c90f6389e85743c08 |
>
> Louis-Paul, you added this package, it seems to fail building with the
> musl C library. Could you have a look ?
>
> > nds32le | keepalived-2.0.15 | NOK | http://autobuild.buildroot.net/results/85af2b037f2b3277a572302acf113c9e11d0223b |
>
> ../lib/liblib.a(parser.o): in function `read_double_func':
> parser.c:(.text+0x734): undefined reference to `__fpclassify'
>
> This feels like a toolchain issue. Nylon, could you have a look ?
>
Actually this is keepalived's configure.ac bug
I issued a problem to the keepalived's Github
https://github.com/acassen/keepalived/issues/1258
And then keepalived's developer has been solved
https://github.com/acassen/keepalived/commit/dea6cfba122439b29cdcb833a59868dd51a4eae4
I pull this commit into my Buildroot,and running "make keepalived" getting build passed
> > m68k | libtorrent-rasterbar-1.2.1 | NOK | http://autobuild.buildroot.net/results/98008526d4b269140dae2462acb77478c79e3ca0 |
>
> disk_io_thread.cpp: In member function 'void libtorrent::disk_io_thread::abort(bool)':
> disk_io_thread.cpp:315:2: internal compiler error: in connect_traces, at dwarf2cfi.c:2802
>
> Romain, you are familiar with many of the compiler bugs that we have on
> weird architectures. Does this one ring any bell ?
>
> > microblazeel | lynx-2.8.9rel.1 | NOK | http://autobuild.buildroot.net/results/23a421e15c32b17ff2f69f183a2e8620ecb93316 |
>
> libiconv issue. According to
> http://autobuild.buildroot.net/?reason=lynx% it only happens once in a
> while. Vadim, you looked at a lot of libiconv/libintl issues, perhaps
> you will have an idea ?
>
> > powerpc64 | netsurf | TIM | http://autobuild.buildroot.net/results/eeb2863c6237aac8428e49a5ee514d43088b0fb8 |
> > x86_64 | netsurf | TIM | http://autobuild.buildroot.net/results/f938fd1515f1d6e11b57aa6e314135789da52a44 |
> > arm | netsurf-3.8 | NOK | http://autobuild.buildroot.net/results/ca4f61a4aba114b04fcf12f66b6266f78807aab8 |
> > m68k | netsurf-3.8 | NOK | http://autobuild.buildroot.net/results/e48416d9ee659dbe9ee3115c4005b2587f08fbe0 |
>
> I submitted
> http://patchwork.ozlabs.org/project/buildroot/list/?series=107046 to
> fix both the timeouts and build failures, even though the fixes are
> quite fragile...
>
> > sparc64 | openjdk-jdk-12+33 | NOK | http://autobuild.buildroot.net/results/47b604d67556087289461d54f6b54f67a41d4b09 |
>
> Some java.nio.file.NoSuchFileException. Adam, it seems to only occur on
> sparc64. Could you confirm that ? If it's the case, perhaps we should
> simply drop sparc64 support in openjdk ?
>
> > aarch64 | python-numpy-1.16.3 | NOK | http://autobuild.buildroot.net/results/50f7f09a9f830cd7b94f8fc83c09fc3d39297d3d |
>
> /home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lcblas -o /tmp/tmph865w02v/a.out
> /home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scnrm2_'
> /home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib/libcblas.so: undefined reference to `scasum_'
> collect2: error: ld returned 1 exit status
> /home/buildroot/autobuild/run/instance-2/output/host/bin/aarch64-linux-gnu-gcc /tmp/tmph865w02v/tmp/tmph865w02v/source.o -L/home/buildroot/autobuild/run/instance-2/output/host/aarch64-buildroot-linux-gnu/sysroot/usr/lib -lblas -o /tmp/tmph865w02v/a.out
> /tmp/tmph865w02v/tmp/tmph865w02v/source.o: In function `main':
> /tmp/tmph865w02v/source.c:6: undefined reference to `cblas_ddot'
> collect2: error: ld returned 1 exit status
>
> I'm not sure what's going on here. Sadly, Samuel who was maintaining
> python-numpy, is no longer active in Buildroot. Is there anyone else
> volunteering to have a look ?
>
> > x86_64 | qt5base-5.12.2 | NOK | http://autobuild.buildroot.net/results/d3fa9fa6d897ac120e716d2e114e0706ac62fae7 |
>
> global/qfloat16_f16c.c:57:6: error: redefinition of 'void qFloatToFloat16_fast(quint16*, const float*, qsizetype)'
> void qFloatToFloat16_fast(quint16 *out, const float *in, qsizetype len) Q_DECL_NOTHROW
> ^~~~~~~~~~~~~~~~~~~~
>
> Peter (Seiderer), any idea ?
>
> > powerpc | qt5multimedia-5.12.2 | NOK | http://autobuild.buildroot.net/results/11790cad7dab795d50b53d44750c838a86039d1f |
>
> qgstreamerplayersession.cpp:400:44: error: cannot convert 'GValue* {aka _GValue*}' to 'void**' for argument '2' to 'GstIteratorResult gst_iterator_next(GstIterator*, void**)'
> while (gst_iterator_next (it, &data) == GST_ITERATOR_OK) {
>
> GStreamer/Qt compatibility issue. Peter (Seiderer), again ? :-)
>
> > mips64el | samba4-4.9.7 | NOK | http://autobuild.buildroot.net/results/28b9caf2e03ff79e32220c7289d34bb8c303abdf |
>
> /home/peko/autobuild/instance-0/output/host/mips64el-buildroot-linux-uclibc/sysroot/usr/include/stdint.h:122:27: error: conflicting types for 'uintptr_t'
> typedef unsigned long int uintptr_t;
> ^
> In file included from ../source3/registry/tests/test_regfio.c:23:0:
> ../third_party/cmocka/cmocka.h:126:28: note: previous declaration of 'uintptr_t' was here
> typedef unsigned int uintptr_t;
>
> Bernd, you are taking care of Samba, could you have a look ?
>
> > i686 | spandsp-20180108 | NOK | http://autobuild.buildroot.net/results/b04da43e67b246cf3c4b2805b8cf6cf0c90197a9 |
>
> gsm0610_rpe.c:132:5: error: invalid 'asm': invalid constraints for operand
> __asm__ __volatile__(
> ^~~~~~~
>
> Bernd, spandsp is also one of your packages, could you have a look ?
>
> > m68k | strace-5.0 | NOK | http://autobuild.buildroot.net/results/c036b11bf1f2fc39f42661634ef3e03360fb85de |
>
> Baruch is proposing http://patchwork.ozlabs.org/patch/1097490/ to avoid
> this build issue.
>
> > powerpc | suricata-4.1.3 | NOK | http://autobuild.buildroot.net/results/d9e53484b6114a6b6271eb1c40c32ddc9fec6fb3 |
>
> This should be fixed by http://patchwork.ozlabs.org/project/buildroot/list/?series=104482.
>
> > aarch64 | vdr-plugin-vnsiserver-v1.8.0 | NOK | http://autobuild.buildroot.net/results/355a4314aa8f36631119841b83f15abe3f8e14ce |
>
> I need to revive an old patch from Fabrice to fix this one.
>
> > powerpc | wireshark-3.0.1 | NOK | http://autobuild.buildroot.net/results/09464861add139bd4048398029f54d75539385b8 | ORPH
>
> Toolchain issue ? Romain, any idea ?
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 15+ messages in thread