* Steve Grubb:
>> 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 sinc
On Friday, October 18, 2019 9:59:11 AM EDT Chris Adams wrote:
> Once upon a time, Tom Hughes said:
>
> > Well I imagine clang will define it when targetting x86_64 output
> > but in this case he is targetting BPF output instead.
> >
> > Adding -D__x86_64__ to the command line may be the quickest
s 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
On 18/10/2019 14:59, Chris Adams wrote:
Once upon a time, Tom Hughes said:
Well I imagine clang will define it when targetting x86_64 output
but in this case he is targetting BPF output instead.
Adding -D__x86_64__ to the command line may be the quickest workaround
for now though.
Yes, but i
Once upon a time, Tom Hughes said:
> Well I imagine clang will define it when targetting x86_64 output
> but in this case he is targetting BPF output instead.
>
> Adding -D__x86_64__ to the command line may be the quickest workaround
> for now though.
Yes, but in my VERY limited understanding, a
On 18/10/2019 14:33, Chris Adams wrote:
Once upon a time, Steve Grubb said:
Not sure how to proceed. I suspect this will be a bigger problem as more
people start to take advantage of the eBPF facility.
I think the issue is that you are building with clang, not gcc. gcc
defines __x86_64__ by
Once upon a time, Steve Grubb said:
> Not sure how to proceed. I suspect this will be a bigger problem as more
> people start to take advantage of the eBPF facility.
I think the issue is that you are building with clang, not gcc. gcc
defines __x86_64__ by default (on the appropriate systems of
imed 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 eB
aving __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.
You need to figure out why the program i
On Thu, 17 Oct 2019 22:21:39 +0100
Tom Hughes wrote:
> On 17/10/2019 21:39, Steve Grubb wrote:
> > On Thursday, October 17, 2019 4:21:44 PM EDT Tom Hughes wrote:
> >> On 17/10/2019 20:44, Steve Grubb wrote:
> >>> I don't think __x86_64__ is defined as the program is aimed at
> >>> eBPF in the
> >
On 17/10/2019 21:39, Steve Grubb wrote:
On Thursday, October 17, 2019 4:21:44 PM EDT Tom Hughes wrote:
On 17/10/2019 20:44, Steve Grubb wrote:
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
re
On Thursday, October 17, 2019 4:21:44 PM EDT Tom Hughes wrote:
> On 17/10/2019 20:44, Steve Grubb wrote:
> > 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 thin
On 17/10/2019 20:44, Steve Grubb wrote:
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 i68
Hello,
I am in the process of building a new version of suricata, and 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/incl
14 matches
Mail list logo
