Hi Mathieu,
I attached an updated series.
I think I fixed up the lint errors. Pardon me.
>> +(define-public libbpf
>> + (let* ((commit "6a1615c263b679c17ecb292fa897f159e826dc10"))
> Why using a specific commit?
> The "0.0.9" is out there :)
I updated the packages where it was appropriate. bc
Hey,
> +(define-public linux-libre-with-bpf
> + (make-linux-libre* linux-libre-5.4-version
> + linux-libre-5.4-source
> + '("x86_64-linux" "i686-linux" "armhf-linux"
> "aarch64-linux" "riscv64-linux")
> + #:extra-version "bpf"
> +
Hello John,
Thanks for this serie, a few remarks below.
> +(define-public libbpf
> + (let* ((commit "6a1615c263b679c17ecb292fa897f159e826dc10"))
Why using a specific commit?
> +(package
> + (name "libbpf")
> + (version "0.0.8")
The "0.0.9" is out there :)
> + (source
> +
Hi Mathieu and Guix,
I managed to build bpftrace finally. I set the build flag
HAVE_BFD_DISASM to false for the package. I am not sure what the
implications will be. No version of libbfd I used (binutils,
clang-toolchain, gcc-toolchain) was free of link errors, so using
HAVE_BFD_DISASM=false ju
Hi Mathieu and Guix,
I forgot to mention that I do have an updated patchset where libbpf is
found. I've attached my work. This is I think closer to the desired
effect but now there is a compile error I do not understand. I hope you
can get further than I did.
- John
>From 6560dc2a5eedb3040bdd5
Thanks Mathieu,
I’ll take a look in a few weeks if you can’t figure it out. I’m probably going
to take a quick break from bpf for a couple weeks as I have become extremely
busy. Thanks for your help.
Oh also I discussed issues I was having on the bpftrace irc and they pointed me
to this pull r
Hello John,
> ld:
> /gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libbfd.a(compress.o):
> undefined reference to symbol 'inflateEnd'
> ld:
> /gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libz.so.1:
> error adding symbols: DSO missing from comman
Hi Mathieu and Guix,
I think I understand this error a little better now. It seems like zlib is
not being resolved correctly.
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/c++ -O2 -g -DNDEBUG
-rdynamic CMakeFiles/bpftrace.dir/attached_probe.cpp.o
CMakeFiles/bpftrace.dir/bpffeatur
Hi Mathieu,
Mathieu Othacehe writes:
> Yes the issue here is that linux-libre-headers is in fact
> linux-libre-headers-5.4.20 which is too old.
>
> I tried to add linux-libre-headers-5.7 to the inputs. Even though it
> comes first in CPLUS_INCLUDE_PATH, GCC is picking the old headers.
I found o
Hello John,
> /tmp/guix-build-bcc-0.14.0.drv-0/source/src/cc/libbpf.c:694:58: error:
> ‘BPF_PROG_TYPE_EXT’ undeclared (first use in this function); did you mean
> ‘BPF_PROG_TYPE_XDP’?
>if (prog_type != BPF_PROG_TYPE_TRACING && prog_type != BPF_PROG_TYPE_EXT)
>
Hi Mathieu,
Mathieu Othacehe writes:
> Now, it's just a matter of packaging "bcc" and "bpftrace" I guess.
I was working on these yesterday. I keep getting errors that seem to
indicate the linux-libre-headers we have might not be compatible:
Here's my definition:
(define-public bcc
(let* ((v
Hello John,
> I was in the mood to try some of these new bpf tools. Does the linux libre
> kernel support it?
Yes it should support it, plus according to this[1], we have the right
Kernel configuration (except maybe for CONFIG_BPF_JIT).
Now, it's just a matter of packaging "bcc" and "bpftrace
12 matches
Mail list logo
