Did you check the following? https://patchwork.ozlabs.org/patch/870656/ https://code.forksand.com/oisf/suricata/commit/7906c521cdde5b1d0eb3ce379b8e343c3055653f Iñaki On Fri, 18 Oct 2019 at 15:22, Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > > On Friday, October 18, 2019 4:39:10 AM EDT Florian Weimer wrote: > > * Steve Grubb: > > > I am in the process of building a new version of suricata, an IDS > > > program that watches network traffic. It has a new module that uses eBPF > > > for high speed network packet categorization. When building, it uses the > > > following command: > > > > > > /usr/bin/clang -Wall -Iinclude -O2 \ > > > > > > -I/usr/include/x86_64-linux-gnu/ \ > > > -D__KERNEL__ -D__ASM_SYSREG_H \ > > > -target bpf -S -emit-llvm xdp_lb.c -o xdp_lb.ll > > > > > > It eventually includes /usr/include/features.h which in turn includes > > > /usr/include/gnu/stubs.h. That file has this code: > > > > > > #if !defined __x86_64__ > > > # include <gnu/stubs-32.h> > > > #endif > > > > > > I don't think __x86_64__ is defined as the program is aimed at eBPF in > > > the kernel. In rawhide, we no longer have glibc-devel(x86-32) to allow > > > this to resolve. However, I think that the assumption of not having > > > __x86_64__ defined means we are targeting i686 is wrong. What should I do? > > > Do we not support eBPF programs on Fedora? > > > > We certainly do not support building eBPF programs against glibc > > headers. There is no eBPF port of glibc, after all. > > Suricata made it through the Debian/Ubuntu build systems. So, that leaves me > trying to figure out how push this through ours since other distros did it. I > have a feeling that it is not using the 32 bit headers at all. It's the > !defined __86_64__ test that causes the file to be pulled in. > > > You need to figure out why the program includes glibc headers, and avoid > > doing that. It's like any other cross-compilation in this regard. > > It's because eBPF programs are written to access the linux kernel internals. > This means it needs to pull in kernel headers to define data structures. The > full chain of includes that leads to the problem is this: > > /usr/lib64/ccache/clang -Wall -Iinclude -O2 \ > -I/usr/include/x86_64-linux-gnu/ \ > -D__KERNEL__ -D__ASM_SYSREG_H \ > -target bpf -S -emit-llvm xdp_lb.c -o xdp_lb.ll > In file included from xdp_lb.c:26: > In file included from /usr/include/linux/if_tunnel.h:6: > In file included from /usr/include/linux/if.h:28: > In file included from /usr/include/sys/socket.h:22: > In file included from /usr/include/features.h:474: > /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found > # include <gnu/stubs-32.h> > ^~~~~~~~~~~~~~~~ > 1 error generated. > > Not sure how to proceed. I suspect this will be a bigger problem as more > people start to take advantage of the eBPF facility. > > -Steve > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx -- Iñaki Úcar _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx