All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexis Lothoré via buildroot" <buildroot@buildroot.org>
To: "Thomas Perale" <thomas.perale@mind.be>,
	"Alexis Lothoré" <alexis.lothore@bootlin.com>,
	"Baruch Siach" <baruch@tkos.co.il>,
	"Thomas Perale via buildroot" <buildroot@buildroot.org>
Cc: "Romain Naour" <romain.naour@smile.fr>
Subject: Re: [Buildroot] [PATCH 2/2] package/iozone: Fix parallel build problem
Date: Fri, 31 Oct 2025 16:39:57 +0100	[thread overview]
Message-ID: <DDWMCTTEL0E6.2MZJ9IJABBCA2@bootlin.com> (raw)
In-Reply-To: <8cc5e53c-edaf-4fc6-806e-e834e12190a2@mind.be>

Hello Thomas,

On Fri Oct 31, 2025 at 4:00 PM CET, Thomas Perale wrote:
> Hi Alexis,
>
> On 10/31/25 10:50 AM, Alexis Lothoré wrote:
>> Hello,
>>
>> On Fri Sep 12, 2025 at 2:50 PM CEST, Baruch Siach via buildroot wrote:
>>> Hi Thomas,
>>>
>>> On Thu, Sep 11 2025, Thomas Perale via buildroot wrote:
>>>> In reply of:
>>>>> Apply a patch from meta-openembedded fixing a cross-build issue [1].
>>>>>
>>>>> [1]
>>>>> https://github.com/openembedded/meta-openembedded/blob/walnascar/meta-oe/recipes-benchmark/iozone3/iozone3/parallelism.patch
>>>>>
>>>>> Fixes:
>>>>> https://gitlab.com/buildroot.org/buildroot/-/jobs/11176774405 (TestIozone)
>>>>>
>>>>> Signed-off-by: Romain Naour <romain.naour@smile.fr>
>>>> Applied to 2025.02.x & 2025.05.x. Thanks
>>> Not in 2025.02.x or 2025.05.x as of a4ac42f4e7a74 ("Revert
>>> "package/firewalld: add missing nftables json runtime dependency"") and
>>> 02f4d62bbf95 ("package/python3: do build-time detection of non-working
>>> toolchain"), respectively.
>> I was investigating a build failure on the iozone package on buildroot
>> 2025.02.x, and eventually found this series which indeed fixes the issues
>> observed locally. As Baruch stated, it does not seem to be applied on
>> 2025.02.x, despite Thomas's notification.
>>
>> Any plan to eventually apply it on 2025.02.x ?
>>
>> Thanks,
>>
>> Alexis
>
> Are you talking about the parallelism issue ? We didn't ended up picking 
> it because the fix came after the version bump which could imply this 
> error only happens after the version bump.

My bad, I did make things confusing by replying to the thread involving the
parallel build fix, but I am indeed referring to the bump to get build
fixes related to GCC raising errors instead of warnings.

> For the bump and the gcc fixes, if i remember correctly I tried to build 
> it locally and it didn't fail. Since the commit message was not specific 
> enough about the error I didn't include it. But I may have done 
> something wrong.
>
> What's the error you are running into ? The bump looks to be small so we 
> might include it as well next week.

Here are the errors I am seeing:

libbif.c:205:1: error: return type defaults to 'int' [-Wimplicit-int]
  205 | create_xls(name)
      | ^~~~~~~~~~
make[2]: *** [<builtin>: libbif.o] Error 1
make[2]: *** Waiting for unfinished jobs....
libasync.c: In function 'end_async':
libasync.c:302:9: error: implicit declaration of function 'del_cache' [-Wimplicit-function-declaration]
  302 |         del_cache(mygc);
      |         ^~~~~~~~~
libasync.c: In function 'async_read':
libasync.c:432:17: error: implicit declaration of function 'takeoff_cache'; did you mean 'alloc_cache'? [-Wimplicit-function-declaration]
  432 |                 takeoff_cache(gc,ce);
      |                 ^~~~~~~~~~~~~
      |                 alloc_cache
libasync.c: At top level:
libasync.c:618:1: warning: conflicting types for 'takeoff_cache'; have 'void(struct cache *, struct cache_ent *)'
  618 | takeoff_cache(struct cache *gc, struct cache_ent *ce)
      | ^~~~~~~~~~~~~
libasync.c:432:17: note: previous implicit declaration of 'takeoff_cache' with type 'void(struct cache *, struct cache_ent *)'
  432 |                 takeoff_cache(gc,ce);
      |                 ^~~~~~~~~~~~~
libasync.c:692:1: warning: conflicting types for 'del_cache'; have 'void()'
  692 | del_cache(gc)
      | ^~~~~~~~~
libasync.c:302:9: note: previous implicit declaration of 'del_cache' with type 'void()'
  302 |         del_cache(mygc);
      |         ^~~~~~~~~
libasync.c: In function 'async_read_no_copy':
libasync.c:815:17: error: implicit declaration of function 'putoninuse' [-Wimplicit-function-declaration]
  815 |                 putoninuse(gc,ce);
      |                 ^~~~~~~~~~
libasync.c: In function 'async_release':
libasync.c:982:9: error: implicit declaration of function 'takeoffinuse' [-Wimplicit-function-declaration]
  982 |         takeoffinuse(gc);
      |         ^~~~~~~~~~~~
libasync.c: At top level:
libasync.c:996:1: warning: conflicting types for 'putoninuse'; have 'void()'
  996 | putoninuse(gc,entry)
      | ^~~~~~~~~~
libasync.c:815:17: note: previous implicit declaration of 'putoninuse' with type 'void()'
  815 |                 putoninuse(gc,ce);
      |                 ^~~~~~~~~~
libasync.c:1017:1: warning: conflicting types for 'takeoffinuse'; have 'void()'
 1017 | takeoffinuse(gc)
      | ^~~~~~~~~~~~
libasync.c:982:9: note: previous implicit declaration of 'takeoffinuse' with type 'void()'
  982 |         takeoffinuse(gc);
      |         ^~~~~~~~~~~~
make[2]: *** [<builtin>: libasync.o] Error 1
make[2]: Leaving directory '/workspace/build/out/output-diamond/build/iozone-3.506/src/current'
make[1]: *** [package/pkg-generic.mk:273: /workspace/build/out/output-diamond/build/iozone-3.506/.stamp_built] Error 2
make[1]: Leaving directory '/workspace/build/build/buildroot'
make: *** [/workspace/build/build/matchbox/buildroot.mk:48: iozone] Error 2

I managed to reproduce the build issue with the following minimal
defconfig on 2025.02.x

BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_NEON=y
BR2_ARM_ENABLE_VFP=y
BR2_ARM_FPU_NEON=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
BR2_PACKAGE_IOZONE=y

If it helps, would you like me to resend the original patch and enrich it
with those info ?

Alexis
>
> Thanks for the message,
> PERALE Thomas




-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2025-10-31 15:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-06 16:25 [Buildroot] [PATCH 1/2] package/iozone: bump to version 3.508 Romain Naour via buildroot
2025-09-06 16:25 ` [Buildroot] [PATCH 2/2] package/iozone: Fix parallel build problem Romain Naour via buildroot
2025-09-11 19:26   ` Thomas Perale via buildroot
2025-09-12 12:50     ` Baruch Siach via buildroot
2025-10-31  9:50       ` Alexis Lothoré via buildroot
2025-10-31 15:00         ` Thomas Perale via buildroot
2025-10-31 15:39           ` Alexis Lothoré via buildroot [this message]
2025-11-01 18:03             ` Thomas Perale via buildroot
2025-11-17 19:51     ` Arnout Vandecappelle via buildroot
2025-09-06 17:03 ` [Buildroot] [PATCH 1/2] package/iozone: bump to version 3.508 Julien Olivain via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DDWMCTTEL0E6.2MZJ9IJABBCA2@bootlin.com \
    --to=buildroot@buildroot.org \
    --cc=alexis.lothore@bootlin.com \
    --cc=baruch@tkos.co.il \
    --cc=romain.naour@smile.fr \
    --cc=thomas.perale@mind.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.