| Summary: | dev-util/bpftool-7.5.0: fails to build with sys-devel/bpf-toolchain-15.1.0_p1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sam James <sam> |
| Component: | Current packages | Assignee: | Holger Hoffstätte <holger> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | proxy-maint |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109558 https://github.com/gentoo/gentoo/pull/41884 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 880545 | ||
| Attachments: |
build.log
Patch to build with bpf-toolchain-15 |
||
|
Description
Sam James
2025-05-01 06:19:57 UTC
I was scratching my head as to how we hadn't hit this earlier, then realised it's because this specific part is built w/ bpf-toolchain (which indeed defaults to -std=gnu23, but I wasn't using snapshots for that, so only seeing it now w/ the release). But it's the same problem as we've seen in the rest of the kernel. I completely missed that you added 15.1.0 already, otherwise I would have tried myself. This happens in the embedded, statically linked part of bpftool's libbpf so I guess I'll try to sprinkle some gnu11 in there. (In reply to Holger Hoffstätte from comment #2) > I'll try to sprinkle some gnu11 in there. That worked and it builds. However vmlinux.h generates a lot of warnings for attributes like .e.g.: ./vmlinux.h:20192:17: warning: 'btf_type_tag' attribute directive ignored [-Wattributes] 20192 | void __attribute__((btf_type_tag("user"))) *user; | ^~~~ Not sure if those are new with 15 (can you verfiy with toolchain-14?) but somehow I get the feeling these should not happen. In related good news: the bpf deduplication seems to work as expected, as the bpftool executable built with toolchain-15 is now even smaller (a few KB) than one built with clang. Also new are libelf warnings: $sudo /tmp/portage/dev-util/bpftool-7.5.0/image/usr/sbin/bpftool prog show libbpf: elf: skipping section(2) .data (size 0) libbpf: elf: skipping unrecognized data section(10) .comment 2: tracing name dump_bpf_map tag db082b09ac2b3688 gpl loaded_at 2025-04-30T20:08:29+0200 uid 0 xlated 280B jited 167B memlock 4096B map_ids 2 btf_id 83 3: tracing name dump_bpf_prog tag b6592473121581e5 gpl loaded_at 2025-04-30T20:08:29+0200 uid 0 xlated 520B jited 737B memlock 4096B map_ids 2 btf_id 83 14: xdp name xdp_dispatcher tag 67ac9f30075bab16 gpl loaded_at 2025-04-30T20:08:30+0200 uid 0 xlated 160B jited 120B memlock 4096B map_ids 7 btf_id 98 23: ext name homeplug_drop tag fbd415544de357c1 gpl loaded_at 2025-04-30T20:08:30+0200 uid 0 xlated 136B jited 92B memlock 4096B btf_id 101 Both the attribute warnings and the libelf messages also happen with 14.2.0_p2, so at least they are consistent. I don't remember if they happened before. Created attachment 927284 [details, diff]
Patch to build with bpf-toolchain-15
Unconditionally add std=gnu11 for the bpf bits linked into the bpftool executable. This works with both bpf-toolchain and clang.
The patch is simple enough, makes it build/work and should be good enough for now, especially considering that we still default to clang. Let me know what you think. The warning messages seem benign, though I'm not sure why a 0-sized data section or a .comment are not just ignored. (In reply to Holger Hoffstätte from comment #9) > Also: https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673841.html Ackshually v2 from last night :-) https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682340.html (In reply to Holger Hoffstätte from comment #9) > Also: https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673841.html Latest version is https://inbox.sourceware.org/gcc-patches/20250430172344.240648-1-david.faust@oracle.com/. (In reply to Holger Hoffstätte from comment #2) > I completely missed that you added 15.1.0 already, otherwise I would have > tried myself. This happens in the embedded, statically linked part of > bpftool's libbpf so I guess I'll try to sprinkle some gnu11 in there. Sorry, I'd meant to ping you for it as I knew you'd be interested! (In reply to Holger Hoffstätte from comment #4) > In related good news: the bpf deduplication seems to work as expected, as > the bpftool executable built with toolchain-15 is now even smaller (a few > KB) than one built with clang. \o/ (In reply to Holger Hoffstätte from comment #7) > Created attachment 927284 [details, diff] [details, diff] > Patch to build with bpf-toolchain-15 > > Unconditionally add std=gnu11 for the bpf bits linked into the bpftool > executable. This works with both bpf-toolchain and clang. LGTM (but not tried it yet). Made a PR and will also send the change to upstream. I expect it will take a while for this to materialize in the bpftool GH mirror. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bf70fbf7b0dc97fbc97af579954ea81a8df36113 commit bf70fbf7b0dc97fbc97af579954ea81a8df36113 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2025-05-01 17:27:57 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-05-02 04:37:27 +0000 dev-util/bpftool: always build bpf bits with std=gnu11, remove py3.10 The bpf-toolchain-15 compiler defaults to C23, which fails to compile various kernel headers due to their use of a custom 'bool' type. Explicitly using -std=gnu11 works with both clang and bpf-toolchain. Closes: https://bugs.gentoo.org/955156 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Part-of: https://github.com/gentoo/gentoo/pull/41884 Signed-off-by: Sam James <sam@gentoo.org> dev-util/bpftool/bpftool-7.5.0.ebuild | 5 ++++- dev-util/bpftool/bpftool-9999.ebuild | 7 +++++-- 2 files changed, 9 insertions(+), 3 deletions(-) Patch submitted upstream: https://lore.kernel.org/bpf/20250502085710.3980-1-holger@applied-asynchrony.com/ |