-
Notifications
You must be signed in to change notification settings - Fork 11
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
[Enhancement Request] Support for Linux ppc64 + ppc64le #205
Comments
It should be possible to compile beats without ebpf support for ppc64, I'm fairly sure you're the first one to try it and hence discover is not working, maybe we screwed up some dependency in the build system. It would be easier to just fix beats to not depend on ebpf for ppc64, would that solve the issue for you? |
It worked previously using the normal This is the error I get when running the package command: [myuser@myhost auditbeat]$ PLATFORMS=linux/ppc64le mage package
Generated fields.yml for auditbeat to /monitoring/go/src/github.com/elastic/beats-ppc/x-pack/auditbeat/fields.yml
>> Building auditbeat.yml for linux/amd64
>> Building auditbeat.reference.yml for linux/amd64
>> Building auditbeat.docker.yml for linux/amd64
>> golangCrossBuild: Building for linux/ppc64le
>> buildGoDaemon: Building for linux/ppc64le
>> Building using: cmd='build/mage-linux-amd64 golangCrossBuild', env=[CC=powerpc64le-linux-gnu-gcc, CXX=powerpc64le-linux-gnu-g++, GOARCH=ppc64le, GOARM=, GOOS=linux, PLATFORM_ID=linux-ppc64le]
>> Building using: cmd='build/mage-linux-amd64 buildGoDaemon', env=[CC=powerpc64le-linux-gnu-gcc, CXX=powerpc64le-linux-gnu-g++, GOARCH=ppc64le, GOARM=, GOOS=linux, PLATFORM_ID=linux-ppc64le]
# github.com/elastic/beats/v7/libbeat/ebpf
../../libbeat/ebpf/watcher_linux.go:52:22: undefined: ebpfevents.Loader
../../libbeat/ebpf/watcher_linux.go:73:25: undefined: ebpfevents.NewLoader
../../libbeat/ebpf/watcher_linux.go:120:28: undefined: ebpfevents.NewLoader
Error: running "go build -o build/golang-crossbuild/auditbeat-linux-ppc64le -buildmode pie -trimpath -ldflags -s -X github.com/elastic/beats/v7/libbeat/version.buildTime=2024-08-29T23:29:49Z -X github.com/elastic/beats/v7/libbeat/version.commit=c1defa232e85ada0847bb10ee7439d49fc35164e" failed with exit code 1
Error: failed building for linux/ppc64le: exit status 1
failed building for linux/ppc64le: exit status 1
package ran for 1m42.560611631s
Error: running "docker run --ulimit nofile=262144:262144 --env EXEC_UID=1629410 --env EXEC_GID=10010 -v /monitoring/go/pkg/mod:/go/pkg/mod:ro --env DEV=false -v /monitoring/oracle/client_ppc64le:/monitoring/oracle --env LD_LIBRARY_PATH=/monitoring/oracle --rm --env GOFLAGS=-mod=readonly -buildvcs=false --env MAGEFILE_VERBOSE= --env MAGEFILE_TIMEOUT= --env SNAPSHOT=false -v /monitoring/go/src/github.com/elastic/beats-ppc:/go/src/github.com/elastic/beats -w /go/src/github.com/elastic/beats/x-pack/auditbeat docker.elastic.co/beats-dev/golang-crossbuild:1.21.11-ppc-debian11 --build-cmd build/mage-linux-amd64 golangCrossBuild --platforms linux/ppc64le" failed with exit code 1 Happy if it's something that can be addressed in the build process, I just thought adding support here would be more extensible since this would also allow us to look at using the universal profiling agent as a potential alternative to Beats and presumably future proof things for when more ebpf improvements get made to the Beats agents. |
Indeed, it seems we have to restrict the build to linux_amd64_arm64, so it doesn't try to use ebpf outside. |
I've opened elastic/beats#40778 on behalf of axrayn. |
Impact
Unknown
Epic/Meta Issue
No response
Planned Version
None
Description
Would it be possible to add in support for both the ppc64 and ppc64le arch types since both architectures seem to be supported by the underlying github.com/cilium/ebpf library.
I understand that Elastic doesn't support Beats/Agent on these architectures, the lack of support for these architectures in this module now means that we can no longer cross-compile any beats that includes ebpf functionality (and therefore Agent) for those architectures ourselves.
The text was updated successfully, but these errors were encountered: