* 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 since other
> distros did it
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
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 wrote:
>
> On Friday, October 18, 2019 4:39:10 AM EDT Florian Weimer wrote:
> > * Steve
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
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 us
* Steve Grubb:
> 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 \
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
13 matches
Mail list logo
