[Buildroot] Analysis of build results for 2021-08-17

[Giulio Benetti]

On 8/19/21 12:24 AM, Giulio Benetti wrote:
> Hello Thomas,
> 
> On 8/18/21 11:44 PM, Thomas Petazzoni wrote:
>> Hello,
>>
>> Matt, Fabrice, Adam, Hervé, Giulio, Bernd, Gwenhael, Arnout, Eric, see
>> below! :-)
>>
>> On Wed, 18 Aug 2021 06:57:22 -0000
>> Thomas Petazzoni <thomas.petazzoni at bootlin.com> wrote:
>>
>>>         branch |  OK | NOK | TIM | TOT |
>>>     2021.02.x  | 34  |  7  |  0  | 41  |
>>>     2021.05.x  | 35  |  7  |  0  | 42  |
>>>       master   | 186 | 30  |  5  | 221 |
>>
>> We're doing really good on the master branch now. Let's see what we
>> have left!
>>
> 
> [SNIP]
> 
>>>       m68k     |      libmodsecurity-3.0.5      | NOK | http://autobuild.buildroot.net/results/b92980a563fe7ee331e70f288ce041be0bf29d40 |
>>
>> /tmp/ccix98g9.s: Assembler messages:
>> /tmp/ccix98g9.s: Fatal error: Tried to convert PC relative branch to absolute jump
>>
>> Another toolchain issue... Adding Giulio in the loop.
>>
> 
> I'm reproducing it now.
> 
>>>       or1k     |         openal-1.21.1          | NOK | http://autobuild.buildroot.net/results/6a2809f8eefdeeaca8a4c61130a8d85511685cfc |
>>
>> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/filter.cpp.o: pc-relative relocation against dynamic symbol alFilteri
>> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: CMakeFiles/OpenAL.dir/al/filter.cpp.o: pc-relative relocation against dynamic symbol alGetFilteri
>> /data/buildroot-autobuilder/instance-0/output-1/per-package/openal/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: final link failed: bad value
>> collect2: error: ld returned 1 exit status
>>
>> Toolchain issue. Giulio, an idea ?
> 
> This waits for you to release new OpenRisc Bootlin toolchain. At
> Buildroot level all OpenRisc patches we're covered(on gcc 11.1.0 too
> from yesterday). So with that you should be able to create the new
> Bootlin OpenRisc Toolchain that will also enable -mcmodel=large for
> libgeos and protobuf, basically they will be both re-enabled for
> OpenRisc :-)
> 
>>>       i586     |  openvmtools-10.3.5-10430147   | NOK | http://autobuild.buildroot.net/results/eb3dfe679536b578a0f16762312a96ada7162095 |
>>
>> /home/buildroot/autobuild/instance-3/output-1/build/openvmtools-10.3.5-10430147/lib/include/vm_assert.h:331:7: error: static assertion failed: "sizeof (unixTime->tv_sec) == 4"
>>     331 |       _Static_assert(e, #e); \
>>
>> Another package not ready with 64-bit time_t it seems.
> 
> Yep
> 
>> We clearly don't have the latest version of open-vm-tools, but it
>> hasn't been fixed upstream:
>> https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/lib/hgfs/hgfsUtil.c#L117
>>
>> This issue is discussed at
>> https://github.com/vmware/open-vm-tools/issues/430. The
>> meta-openembedded layer has the patch
>> ./meta-networking/recipes-support/open-vm-tools/open-vm-tools/0001-Make-HgfsConvertFromNtTimeNsec-aware-of-64-bit-time_.patch
>> to fix this.
>>
>> Anyone volunteering to fix this?
>>
> 
> I can do that. Only that patch URL is broken but there is a PR for that
> to take the patch:
> https://github.com/vmware/open-vm-tools/pull/387/commits/3f0580f2546de8be7acf1bc78a55a257bc638ebe
> I can deal with it.

This is fixed by:
https://patchwork.ozlabs.org/project/buildroot/patch/20210818235907.906265-1-giulio.benetti@benettiengineering.com/
-- 
Giulio Benetti
Benetti Engineering sas

> Also we don't have a maintainer for it, maybe I can
> be the one.
> 
>>>       or1k     |            unknown             | NOK | http://autobuild.buildroot.net/results/92c086b0c5c2a298a82a6eb9c289dc53c58a5e5e |
>>
>> Top-level parallel build, no idea what the issue is.
> 
> Can somebody point me some idea on how to approach Top-level parallel
> build debugging? I also have some udisks package failure due to that.
> I mean, now what I do is ./br_reproduce_build SHA1, then I CTRL-C and:
> # cd SHA1
> # cd output
> # make package-that-fails
> 
> But with Top-level I have more output-x, how can I reissue the command
> and are there any trick to debug it?
> 
>>>       or1k     |          zeromq-4.3.4          | NOK | http://autobuild.buildroot.net/results/f6d9c3b1e7be0e3c722f79bad7b89c7f1bd0f2f0 |
>>>       or1k     |          zeromq-4.3.4          | NOK | http://autobuild.buildroot.net/results/c6b4f37e30b7c6f803d32e6d9d0dec8e15e7ec30 |
>>
>> Giulio ?
> 
> Here is the same that goes for openal, external Bootlin OpenRisc
> Toolchain updated must solve it.
> 
> Best regards
>