-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compilation of minimal failing because kernel header path not in includes #1
Comments
Another observation: clang does seem to want to search that arch-specific dir when not using
|
Oh, I think this is how we deal with it in kernel selftests: https://github.com/torvalds/linux/blob/master/tools/testing/selftests/bpf/Makefile#L215-L224 This seems to be due to using Do you mind trying the |
It works indeed. Would you like a patch? |
that would be great, thanks. Please also include a comment explaining why we need that. |
Add architecture-specific headers to the BPF compilation command, otherwise they're missing on some systems (at least on x86-64 Ubuntu). Fixes libbpf#1
Add architecture-specific headers to the BPF compilation command, otherwise they're missing on some systems (at least on x86-64 Ubuntu). Fixes libbpf#1
Add architecture-specific headers to the BPF compilation command, otherwise they're missing on some systems (at least on x86-64 Ubuntu). Fixes libbpf#1
Add architecture-specific headers to the BPF compilation command, otherwise they're missing on some systems (at least on x86-64 Ubuntu). Fixes #1
The program accepts 3 connections and then splits the data from the first one to the other two. The data is split on a packet boundary and the packets are alternated betwen the connections. So for multiple packets it looks like this: - packet 0 -> connection 1, - packet 1 -> connection 2, - packet 2 -> connection 1, - packet 3 -> connection 2, etc. The easiest way to test it is using netcat: [shell 0] $ src/sockmap 127.0.0.1 1024 [shell 1] $ nc 127.0.0.1 1024 [shell 2] $ nc 127.0.0.1 1024 [shell 3] $ nc 127.0.0.1 1024 Writing something on shell libbpf#1 will cause it to be redirected and output to shell libbpf#2. A second write will be redirectd it to shell libbpf#3, another one to shell libbpf#2, then libbpf#3, etc. Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
The program accepts 3 connections and then splits the data from the first one to the other two. The data is split on a packet boundary and the packets are alternated betwen the connections. So for multiple packets it looks like this: - packet 0 -> connection 1, - packet 1 -> connection 2, - packet 2 -> connection 1, - packet 3 -> connection 2, etc. The easiest way to test it is using netcat: [shell 0] $ src/sockmap 127.0.0.1 1024 [shell 1] $ nc 127.0.0.1 1024 [shell 2] $ nc 127.0.0.1 1024 [shell 3] $ nc 127.0.0.1 1024 Writing something on shell libbpf#1 will cause it to be redirected and output to shell libbpf#2. A second write will be redirectd it to shell libbpf#3, another one to shell libbpf#2, then libbpf#3, etc. Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
On Ubuntu 20.10 this happens to me:
The rub seems to be that
/usr/include/linux/types.h
wantsasm/types.h
which, on my system, I believe lives in/usr/include/x86_64-linux-gnu/asm/types.h
(which file just reads#include <asm-generic/types.h>
), and/usr/include/x86_64-linux-gnu
does not seem to be among clang's include paths, as demonstrated by theclang -v
output below.FWIW, on the gcc side, the preprocessor includes
/usr/include/x86_64-linux-gnu
in thecpp -v
output.I'm not sure who's at fault here, or what the correct fix is, but adding
-I/usr/include/x86_64-linux-gnu
makes it work. Changing the source to usevmlinux.h
instead of<linux/bpf.h>
also makes it work.Although I don't believe it to be the case, it is possible that my system got screwed up by me manually installing kernel headers through the Debian package created by the kernel's
deb-pkg
make target. I don't think it's the case because I've verified that/usr/include/linux/types.h
corresponds to the file provided by the Ubuntu'slinux-libc-dev
package.The text was updated successfully, but these errors were encountered: