Build fails with libbpf > 0.8.x, can only build kernel when using exact submodule commit #49
Comments
|
I've reproduced the above using the latest available commit, d584761. |
Apteryks
changed the title
Apteryks
changed the title
|
I had to use libbpf 0.8.3. |
|
Although it built fine, compiling the Linux kernel with CONFIG_DEBUG_INFO would fail with a It seems dwarves is very tightly coupled to the inner workings of libbpf? It'd be nice if it targetted at least a released version of libbpf. |
Apteryks
changed the title
Apteryks
changed the title
|
nixpkgs builds pahole with libbpf v1.4.1, so either of us are doing something wrong - please provide a reproducer or explain how you're building |
|
Hi! It's fairly easy to reproduce for me, using libbpf v1.4.1, ensuring I don't pull the git submodules of dwarves, specifying the "-DLIBBPF_EMBEDDED=OFF" build option and providing |
|
I note that |
|
I found the underlying issue: libbpf/libbpf#562 |
|
I note that the default headers used in the build environment on Guix are at 5.15.49, while Nix uses 6.7, which is probably why it works there. |
|
If I add the headers of 6.8 to the build environment, it builds fine, so it seems the #562 fix of libbpf is insufficient, at least for kernel headers as old as 5.15.49. |
|
Fails as well on 5.15.157. I'll report that the fix doesn't work for 5.15.X on the libbpf issue. |
It's a bit worse than that, for bpf-related headers we install the headers that were shipped in libbpf, so we always build with whatever is compatible with libbpf (this is actually a bit of a hack as I don't see where we give it priority over linux headers... but it seems to work out in practice) without worrying about what kernel includes are used: (We do this because we also had quite a few problems with older linux headers in the past, as some libbpf releases depended on non-released kernels. using newer libbpf headers is fine as kernel headers are guaranteed to be backwards compatible.) Either way it's not a dwarves problem, you probably cannot build anything with libbpf in that configuration (newer libbpf and older linux/bpf.h), so this probably should be closed in favor of a new issue in libbpf. |
|
I've pinged the libbpf people at: libbpf/libbpf#562 (comment). |
|
Sorry, I should have checked the actual error here before speaking, it's not really a libbpf problem. libbpf 1.x provides APIs that use btf_enum64, but the I guess pahole could add a check for it and either skip the code or redefine the enum, but there's no easy define to check for this so frankly you'll be better off upgrading your linux headers or using libbpf's uapi files like nix does... |
|
Hm, upgrading the linux-kernel-headers will have to wait until the next core updates iteration for Guix. Meanwhile copying the whole Linux 6.8 headers would add 6.8 MiB to the size of libbpf. Not great. Perhaps I could do with just bpf.h and types.h and a few others... |
|
Also, what is |
|
I've added the following phase to libbpf, which emulates what's done in Nix using the least amount of Linux headers: (add-after 'install 'install-linux-bpf-headers
;; Workaround users such as 'dwarves' requiring btf_enum64
;; definition from the kernel Linux >= 6 headers (see:
;; https://github.com/acmel/dwarves/issues/49).
;; TODO: Remove once our 'linux-libre-headers' package is
;; upgraded to a >= 6 release.
(lambda _
(let ((linux-libre-headers #$(this-package-native-input
"linux-libre-headers")))
(for-each (lambda (f)
(install-file (string-append linux-libre-headers
"/include/" f)
(string-append #$output "/include/"
(dirname f))))
;; This list contains btf.h and its transitive
;; dependencies.
(list "asm/posix_types.h"
"asm/types.h"
"asm-generic/types.h"
"asm-generic/int-ll64.h"
"linux/btf.h"
"linux/posix_types.h"
"linux/stddef.h"
"linux/types.h")))))It adds about 100 KiB of overhead, and appears to resolve the issues. |
The build fails like:
The text was updated successfully, but these errors were encountered: