* cross compiling perf
@ 2016-06-15 14:24 Milian Wolff
2016-06-15 15:47 ` Kim Phillips
2016-06-16 16:11 ` Arnaldo Carvalho de Melo
0 siblings, 2 replies; 15+ messages in thread
From: Milian Wolff @ 2016-06-15 14:24 UTC (permalink / raw)
To: linux-perf-users
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
Hey all,
I'm trying to compile a more modern version of the user-space perf tools for
an arm64 embedded target. So far, no cigar.
Neither tools/build/Documentation nor tools/perf/Documentation/Build.txt
explain how this should be done. Right now, I'm trying the following from an
SDK with an environment that already sets up CC, CFLAGS etc. pp.
[SDK] ~/milian/linux/tools/perf$ make ARCH=arm64 CROSS_COMPILE=/home/sdk/
sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux/aarch64-gnu-linux-
CFLAGS="--sysroot=/home/sdk/sysroots/aarch64-gnu-linux -I/home/milian/target-
prefix/include -L/home/milian/target-prefix/lib $CFLAGS"
BUILD: Doing 'make -j8' parallel build
Auto-detecting system features:
... dwarf: [ OFF ]
... dwarf_getlocations: [ OFF ]
... glibc: [ OFF ]
... gtk2: [ OFF ]
... libaudit: [ OFF ]
... libbfd: [ OFF ]
... libelf: [ OFF ]
... libnuma: [ OFF ]
... numa_num_possible_cpus: [ OFF ]
... libperl: [ OFF ]
... libpython: [ OFF ]
... libslang: [ OFF ]
... libcrypto: [ OFF ]
... libunwind: [ OFF ]
... libdw-dwarf-unwind: [ OFF ]
... zlib: [ OFF ]
... lzma: [ OFF ]
... get_cpuid: [ OFF ]
... bpf: [ OFF ]
config/Makefile:272: *** No gnu/libc-version.h found, please install glibc-
dev[el]. Stop
How can I figure out where perf's buildsystem is looking for the dependencies?
How can I configure it to look into both, my sysroot as well as a secondary
path that contains some additional software I compiled manually?
Thanks
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-06-15 14:24 cross compiling perf Milian Wolff
@ 2016-06-15 15:47 ` Kim Phillips
2016-06-27 11:56 ` Milian Wolff
2016-06-16 16:11 ` Arnaldo Carvalho de Melo
1 sibling, 1 reply; 15+ messages in thread
From: Kim Phillips @ 2016-06-15 15:47 UTC (permalink / raw)
To: Milian Wolff; +Cc: linux-perf-users
On Wed, 15 Jun 2016 16:24:52 +0200
Milian Wolff <milian.wolff@kdab.com> wrote:
> I'm trying to compile a more modern version of the user-space perf tools for
> an arm64 embedded target. So far, no cigar.
...
> config/Makefile:272: *** No gnu/libc-version.h found, please install glibc-
> dev[el]. Stop
fwiw, I've had marginally greater success in the past by perfoming an
arm64-cross 'make defconfig; make -C tools/perf clean perf' before
switching to building fully-featured perfs natively.
Kim
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-06-15 14:24 cross compiling perf Milian Wolff
2016-06-15 15:47 ` Kim Phillips
@ 2016-06-16 16:11 ` Arnaldo Carvalho de Melo
2016-06-17 9:49 ` Milian Wolff
1 sibling, 1 reply; 15+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-06-16 16:11 UTC (permalink / raw)
To: Milian Wolff; +Cc: linux-perf-users
Em Wed, Jun 15, 2016 at 04:24:52PM +0200, Milian Wolff escreveu:
> I'm trying to compile a more modern version of the user-space perf tools for
> an arm64 embedded target. So far, no cigar.
> Neither tools/build/Documentation nor tools/perf/Documentation/Build.txt
> explain how this should be done. Right now, I'm trying the following from an
> SDK with an environment that already sets up CC, CFLAGS etc. pp.
> [SDK] ~/milian/linux/tools/perf$ make ARCH=arm64 CROSS_COMPILE=/home/sdk/
> sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux/aarch64-gnu-linux-
> CFLAGS="--sysroot=/home/sdk/sysroots/aarch64-gnu-linux -I/home/milian/target-
> prefix/include -L/home/milian/target-prefix/lib $CFLAGS"
> BUILD: Doing 'make -j8' parallel build
> Auto-detecting system features:
> ... dwarf: [ OFF ]
> ... dwarf_getlocations: [ OFF ]
> ... glibc: [ OFF ]
> ... gtk2: [ OFF ]
> ... libaudit: [ OFF ]
> ... libbfd: [ OFF ]
> ... libelf: [ OFF ]
> ... libnuma: [ OFF ]
> ... numa_num_possible_cpus: [ OFF ]
> ... libperl: [ OFF ]
> ... libpython: [ OFF ]
> ... libslang: [ OFF ]
> ... libcrypto: [ OFF ]
> ... libunwind: [ OFF ]
> ... libdw-dwarf-unwind: [ OFF ]
> ... zlib: [ OFF ]
> ... lzma: [ OFF ]
> ... get_cpuid: [ OFF ]
> ... bpf: [ OFF ]
>
> config/Makefile:272: *** No gnu/libc-version.h found, please install glibc-
> dev[el]. Stop
> How can I figure out where perf's buildsystem is looking for the dependencies?
> How can I configure it to look into both, my sysroot as well as a secondary
> path that contains some additional software I compiled manually?
So, I have these cross build images here:
[root@jouet ~]# docker images | grep -- -x-
perf-build-minimal-debian-experimental-x-mips64 latest 53b5bb082ace 11 weeks ago 595.3 MB
perf-build-minimal-debian-experimental-x-mips64el latest 427fa4c1ad0a 11 weeks ago 595.4 MB
perf-build-minimal-debian-experimental-x-mipsel latest 1247b61110bf 11 weeks ago 589.4 MB
perf-build-minimal-ubuntu-x-arm latest cb739975a1f0 11 weeks ago 380.5 MB
perf-build-minimal-ubuntu-x-arm64 latest 83fa1b24c6b6 11 weeks ago 357.2 MB
perf-build-minimal-ubuntu-x-ppc64 latest b759a1866191 11 weeks ago 384.3 MB
perf-build-minimal-ubuntu-x-ppc64el latest a3f1e718196a 11 weeks ago 372.3 MB
[root@jouet ~]#
But those are minimal builds, without that many devel packages, have
to go back looking for multiarch libs in debian, anyway, it works
a bit better than what you have experienced:
[root@jouet ubuntu-x-arm64]# cat Dockerfile
FROM docker.io/ubuntu
MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
#ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update -y
RUN apt-get upgrade -y
RUN apt-get install -y make gcc-aarch64-linux-gnu flex bison
# buildable!
# ubuntu doesn't have the other devel packages for arm64, so build just the basic tool
RUN mkdir -p /tmp/build/perf
ENTRYPOINT make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C /git/linux/tools/perf O=/tmp/build/perf
[root@jouet ubuntu-x-arm64]#
[root@jouet ubuntu-x-arm64]# docker run -v /home/acme/git:/git:Z --rm=true -t -i perf-build-minimal-ubuntu-x-arm64
make: Entering directory `/git/linux/tools/perf'
BUILD: Doing 'make -j4' parallel build
sh: 1: command: Illegal option -c
Auto-detecting system features:
... dwarf: [ OFF ]
... dwarf_getlocations: [ OFF ]
... glibc: [ on ]
... gtk2: [ OFF ]
... libaudit: [ OFF ]
... libbfd: [ OFF ]
... libelf: [ OFF ]
... libnuma: [ OFF ]
... numa_num_possible_cpus: [ OFF ]
... libperl: [ OFF ]
... libpython: [ OFF ]
... libslang: [ OFF ]
... libcrypto: [ OFF ]
... libunwind: [ OFF ]
... libdw-dwarf-unwind: [ OFF ]
... zlib: [ OFF ]
... lzma: [ OFF ]
... get_cpuid: [ OFF ]
... bpf: [ on ]
config/Makefile:260: No libelf found, disables 'probe' tool and BPF support in 'perf record', please install elfutils-libelf-devel/libelf-dev
config/Makefile:413: Disabling post unwind, no support found.
config/Makefile:459: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev
config/Makefile:470: No libcrypto.h found, disables jitted code injection, please install libssl-devel or libssl-dev
config/Makefile:485: slang not found, disables TUI support. Please install slang-devel or libslang-dev
config/Makefile:499: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev
config/Makefile:527: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev
config/Makefile:553: No python interpreter was found: disables Python support - please install python-devel/python-dev
config/Makefile:660: No liblzma found, disables xz kernel module decompression, please install xz-devel/liblzma-dev
config/Makefile:673: No numa.h found, disables 'perf bench numa mem' benchmark, please install numactl-devel/libnuma-devel/libnuma-dev
config/Makefile:730: Your gcc lacks the __get_cpuid() builtin, disables support for auxtrace/Intel PT, please install a newer gcc
GEN /tmp/build/perf/common-cmds.h
MKDIR /tmp/build/perf/fd/
CC /tmp/build/perf/fd/array.o
CC /tmp/build/perf/event-parse.o
CC /tmp/build/perf/exec-cmd.o
MKDIR /tmp/build/perf/fd/
LD /tmp/build/perf/fd/libapi-in.o
MKDIR /tmp/build/perf/fs/
CC /tmp/build/perf/fs/fs.o
CC /tmp/build/perf/help.o
PERF_VERSION = 4.7.0-rc3
CC /tmp/build/perf/plugin_jbd2.o
CC /tmp/build/perf/event-plugin.o
LD /tmp/build/perf/plugin_jbd2-in.o
CC /tmp/build/perf/plugin_hrtimer.o
CC /tmp/build/perf/trace-seq.o
LD /tmp/build/perf/plugin_hrtimer-in.o
CC /tmp/build/perf/plugin_kmem.o
MKDIR /tmp/build/perf/fs/
CC /tmp/build/perf/fs/tracing_path.o
CC /tmp/build/perf/parse-filter.o
LD /tmp/build/perf/plugin_kmem-in.o
CC /tmp/build/perf/plugin_kvm.o
LD /tmp/build/perf/plugin_kvm-in.o
CC /tmp/build/perf/plugin_mac80211.o
MKDIR /tmp/build/perf/fs/
LD /tmp/build/perf/fs/libapi-in.o
CC /tmp/build/perf/cpu.o
CC /tmp/build/perf/pager.o
LD /tmp/build/perf/plugin_mac80211-in.o
CC /tmp/build/perf/plugin_sched_switch.o
CC /tmp/build/perf/debug.o
CC /tmp/build/perf/parse-utils.o
LD /tmp/build/perf/libapi-in.o
CC /tmp/build/perf/kbuffer-parse.o
AR /tmp/build/perf/libapi.a
GEN perf-archive
GEN perf-with-kcore
CC /tmp/build/perf/parse-options.o
LD /tmp/build/perf/plugin_sched_switch-in.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/plugin_function.o
CC /tmp/build/perf/util/alias.o
LD /tmp/build/perf/libtraceevent-in.o
LINK /tmp/build/perf/libtraceevent.a
CC /tmp/build/perf/builtin-bench.o
LD /tmp/build/perf/plugin_function-in.o
CC /tmp/build/perf/plugin_xen.o
LD /tmp/build/perf/plugin_xen-in.o
CC /tmp/build/perf/plugin_scsi.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/annotate.o
LD /tmp/build/perf/plugin_scsi-in.o
CC /tmp/build/perf/plugin_cfg80211.o
LD /tmp/build/perf/plugin_cfg80211-in.o
LINK /tmp/build/perf/plugin_jbd2.so
CC /tmp/build/perf/builtin-annotate.o
LINK /tmp/build/perf/plugin_hrtimer.so
LINK /tmp/build/perf/plugin_kmem.so
LINK /tmp/build/perf/plugin_kvm.so
LINK /tmp/build/perf/plugin_mac80211.so
LINK /tmp/build/perf/plugin_sched_switch.so
LINK /tmp/build/perf/plugin_function.so
LINK /tmp/build/perf/plugin_xen.so
LINK /tmp/build/perf/plugin_scsi.so
LINK /tmp/build/perf/plugin_cfg80211.so
GEN /tmp/build/perf/libtraceevent-dynamic-list
MKDIR /tmp/build/perf/arch/
CC /tmp/build/perf/arch/common.o
CC /tmp/build/perf/run-command.o
CC /tmp/build/perf/builtin-config.o
CC /tmp/build/perf/sigchain.o
CC /tmp/build/perf/builtin-diff.o
MKDIR /tmp/build/perf/arch/arm64/util/
LD /tmp/build/perf/arch/arm64/util/libperf-in.o
MKDIR /tmp/build/perf/arch/arm64/
LD /tmp/build/perf/arch/arm64/libperf-in.o
MKDIR /tmp/build/perf/arch/
LD /tmp/build/perf/arch/libperf-in.o
MKDIR /tmp/build/perf/ui/
CC /tmp/build/perf/ui/setup.o
CC /tmp/build/perf/subcmd-config.o
LD /tmp/build/perf/libsubcmd-in.o
AR /tmp/build/perf/libsubcmd.a
MKDIR /tmp/build/perf/ui/
CC /tmp/build/perf/ui/helpline.o
MKDIR /tmp/build/perf/ui/
CC /tmp/build/perf/ui/progress.o
MKDIR /tmp/build/perf/ui/
CC /tmp/build/perf/ui/util.o
MKDIR /tmp/build/perf/ui/
CC /tmp/build/perf/ui/hist.o
MKDIR /tmp/build/perf/ui/stdio/
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/build-id.o
CC /tmp/build/perf/ui/stdio/hist.o
CC /tmp/build/perf/builtin-evlist.o
CC /tmp/build/perf/builtin-help.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/config.o
CC /tmp/build/perf/builtin-sched.o
CC /tmp/build/perf/builtin-buildid-list.o
CC /tmp/build/perf/builtin-buildid-cache.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/ctype.o
MKDIR /tmp/build/perf/ui/
LD /tmp/build/perf/ui/libperf-in.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/db-export.o
MKDIR /tmp/build/perf/scripts/
LD /tmp/build/perf/scripts/libperf-in.o
CC /tmp/build/perf/builtin-list.o
CC /tmp/build/perf/builtin-record.o
CC /tmp/build/perf/builtin-report.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/env.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/event.o
CC /tmp/build/perf/builtin-stat.o
CC /tmp/build/perf/builtin-timechart.o
CC /tmp/build/perf/builtin-top.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/evlist.o
CC /tmp/build/perf/builtin-script.o
CC /tmp/build/perf/builtin-kmem.o
CC /tmp/build/perf/builtin-lock.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/evsel.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/evsel_fprintf.o
CC /tmp/build/perf/builtin-kvm.o
CC /tmp/build/perf/builtin-inject.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/find_bit.o
MKDIR /tmp/build/perf/util/
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/kallsyms.o
CC /tmp/build/perf/util/levenshtein.o
CC /tmp/build/perf/builtin-mem.o
CC /tmp/build/perf/builtin-data.o
CC /tmp/build/perf/builtin-version.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/llvm-utils.o
MKDIR /tmp/build/perf/util/
BISON /tmp/build/perf/util/parse-events-bison.c
MKDIR /tmp/build/perf/bench/
CC /tmp/build/perf/bench/sched-messaging.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/builtin-test.o
CC /tmp/build/perf/perf.o
MKDIR /tmp/build/perf/bench/
CC /tmp/build/perf/bench/sched-pipe.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/perf_regs.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/parse-events.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/path.o
MKDIR /tmp/build/perf/bench/
CC /tmp/build/perf/bench/mem-functions.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/rbtree.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/libstring.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/bitmap.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/hweight.o
MKDIR /tmp/build/perf/bench/
CC /tmp/build/perf/bench/futex-hash.o
MKDIR /tmp/build/perf/bench/
CC /tmp/build/perf/bench/futex-wake.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/quote.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/strbuf.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/string.o
MKDIR /tmp/build/perf/bench/
CC /tmp/build/perf/bench/futex-wake-parallel.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/strlist.o
MKDIR /tmp/build/perf/bench/
CC /tmp/build/perf/bench/futex-requeue.o
MKDIR /tmp/build/perf/bench/
CC /tmp/build/perf/bench/futex-lock-pi.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/strfilter.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/top.o
MKDIR /tmp/build/perf/bench/
LD /tmp/build/perf/bench/perf-in.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/usage.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/dso.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/symbol.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/symbol_fprintf.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/color.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/dso-data.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/header.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/callchain.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/attr.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/values.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/vmlinux-kallsyms.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/debug.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/openat-syscall.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/machine.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/openat-syscall-all-cpus.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/openat-syscall-tp-fields.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/mmap-basic.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/perf-record.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/evsel-roundtrip-name.o
MKDIR /tmp/build/perf/tests/
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/map.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/pstack.o
CC /tmp/build/perf/tests/evsel-tp-sched.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/session.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/fdarray.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/ordered-events.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/pmu.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/hists_common.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/comm.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/thread.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/hists_link.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/thread_map.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/trace-event-parse.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/hists_filter.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/parse-events-bison.o
MKDIR /tmp/build/perf/util/
BISON /tmp/build/perf/util/pmu-bison.c
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/trace-event-read.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/hists_output.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/trace-event-info.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/trace-event-scripting.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/trace-event.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/svghelper.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/sort.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/hists_cumulate.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/hist.o
MKDIR /tmp/build/perf/tests/
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/tests/python-use.o
CC /tmp/build/perf/util/util.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/bp_signal.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/bp_signal_overflow.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/task-exit.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/sw-clock.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/mmap-thread-lookup.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/thread-mg-share.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/switch-tracking.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/keep-tracking.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/xyarray.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/cpumap.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/code-reading.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/cgroup.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/sample-parsing.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/target.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/rblist.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/intlist.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/vdso.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/parse-no-sample-id-all.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/kmod-path.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/counts.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/thread-map.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/stat.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/stat-shadow.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/llvm.o
MKDIR /tmp/build/perf/tests/
MKDIR /tmp/build/perf/tests/
MKDIR /tmp/build/perf/tests/
MKDIR /tmp/build/perf/tests/
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/bpf.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/record.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/topology.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/cpumap.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/stat.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/event_update.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/srcline.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/event-times.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/backward-ring-buffer.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/data.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/llvm-src-base.o
MKDIR /tmp/build/perf/util/
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/util/tsc.o
CC /tmp/build/perf/tests/llvm-src-kbuild.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/llvm-src-prologue.o
MKDIR /tmp/build/perf/tests/
CC /tmp/build/perf/tests/llvm-src-relocation.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/cloexec.o
MKDIR /tmp/build/perf/tests/
LD /tmp/build/perf/tests/perf-in.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/call-path.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/thread-stack.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/parse-branch-options.o
LD /tmp/build/perf/perf-in.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/parse-regs-options.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/term.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/help-unknown-cmd.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/mem-events.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/symbol-minimal.o
MKDIR /tmp/build/perf/util/scripting-engines/
LD /tmp/build/perf/util/scripting-engines/libperf-in.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/demangle-java.o
MKDIR /tmp/build/perf/util/
FLEX /tmp/build/perf/util/parse-events-flex.c
MKDIR /tmp/build/perf/util/
FLEX /tmp/build/perf/util/pmu-flex.c
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/pmu-bison.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/parse-events.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/parse-events-flex.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/pmu.o
MKDIR /tmp/build/perf/util/
CC /tmp/build/perf/util/pmu-flex.o
MKDIR /tmp/build/perf/util/
LD /tmp/build/perf/util/libperf-in.o
LD /tmp/build/perf/libperf-in.o
AR /tmp/build/perf/libperf.a
LINK /tmp/build/perf/perf
make: Leaving directory `/git/linux/tools/perf'
[root@jouet ubuntu-x-arm64]#
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-06-16 16:11 ` Arnaldo Carvalho de Melo
@ 2016-06-17 9:49 ` Milian Wolff
2016-06-17 11:00 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 15+ messages in thread
From: Milian Wolff @ 2016-06-17 9:49 UTC (permalink / raw)
To: acme; +Cc: linux-perf-users
[-- Attachment #1: Type: text/plain, Size: 6898 bytes --]
On Donnerstag, 16. Juni 2016 13:11:11 CEST Arnaldo Carvalho de Melo wrote:
> Em Wed, Jun 15, 2016 at 04:24:52PM +0200, Milian Wolff escreveu:
> > I'm trying to compile a more modern version of the user-space perf tools
> > for an arm64 embedded target. So far, no cigar.
> >
> > Neither tools/build/Documentation nor tools/perf/Documentation/Build.txt
> > explain how this should be done. Right now, I'm trying the following from
> > an SDK with an environment that already sets up CC, CFLAGS etc. pp.
> >
> > [SDK] ~/milian/linux/tools/perf$ make ARCH=arm64 CROSS_COMPILE=/home/sdk/
> > sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux/aarch64-gnu-linux-
> > CFLAGS="--sysroot=/home/sdk/sysroots/aarch64-gnu-linux
> > -I/home/milian/target- prefix/include -L/home/milian/target-prefix/lib
> > $CFLAGS"
> >
> > BUILD: Doing 'make -j8' parallel build
> >
> > Auto-detecting system features:
> > ... dwarf: [ OFF ]
> > ... dwarf_getlocations: [ OFF ]
> > ... glibc: [ OFF ]
> > ... gtk2: [ OFF ]
> > ... libaudit: [ OFF ]
> > ... libbfd: [ OFF ]
> > ... libelf: [ OFF ]
> > ... libnuma: [ OFF ]
> > ... numa_num_possible_cpus: [ OFF ]
> > ... libperl: [ OFF ]
> > ... libpython: [ OFF ]
> > ... libslang: [ OFF ]
> > ... libcrypto: [ OFF ]
> > ... libunwind: [ OFF ]
> > ... libdw-dwarf-unwind: [ OFF ]
> > ... zlib: [ OFF ]
> > ... lzma: [ OFF ]
> > ... get_cpuid: [ OFF ]
> > ... bpf: [ OFF ]
> >
> > config/Makefile:272: *** No gnu/libc-version.h found, please install
> > glibc-
> > dev[el]. Stop
> >
> > How can I figure out where perf's buildsystem is looking for the
> > dependencies? How can I configure it to look into both, my sysroot as
> > well as a secondary path that contains some additional software I
> > compiled manually?
>
> So, I have these cross build images here:
>
> [root@jouet ~]# docker images | grep -- -x-
> perf-build-minimal-debian-experimental-x-mips64 latest 53b5bb082ace 11
> weeks ago 595.3 MB perf-build-minimal-debian-experimental-x-mips64el
> latest 427fa4c1ad0a 11 weeks ago 595.4 MB
> perf-build-minimal-debian-experimental-x-mipsel latest 1247b61110bf 11
> weeks ago 589.4 MB perf-build-minimal-ubuntu-x-arm
> latest cb739975a1f0 11 weeks ago 380.5 MB
> perf-build-minimal-ubuntu-x-arm64 latest 83fa1b24c6b6 11
> weeks ago 357.2 MB perf-build-minimal-ubuntu-x-ppc64
> latest b759a1866191 11 weeks ago 384.3 MB
> perf-build-minimal-ubuntu-x-ppc64el latest a3f1e718196a 11
> weeks ago 372.3 MB [root@jouet ~]#
>
> But those are minimal builds, without that many devel packages, have
> to go back looking for multiarch libs in debian, anyway, it works
> a bit better than what you have experienced:
>
> [root@jouet ubuntu-x-arm64]# cat Dockerfile
> FROM docker.io/ubuntu
> MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
> #ENV DEBIAN_FRONTEND noninteractive
> RUN apt-get update -y
> RUN apt-get upgrade -y
> RUN apt-get install -y make gcc-aarch64-linux-gnu flex bison
> # buildable!
> # ubuntu doesn't have the other devel packages for arm64, so build just the
> basic tool RUN mkdir -p /tmp/build/perf
> ENTRYPOINT make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C
> /git/linux/tools/perf O=/tmp/build/perf [root@jouet ubuntu-x-arm64]#
> [root@jouet ubuntu-x-arm64]# docker run -v /home/acme/git:/git:Z --rm=true
> -t -i perf-build-minimal-ubuntu-x-arm64 make: Entering directory
> `/git/linux/tools/perf'
> BUILD: Doing 'make -j4' parallel build
> sh: 1: command: Illegal option -c
>
> Auto-detecting system features:
> ... dwarf: [ OFF ]
> ... dwarf_getlocations: [ OFF ]
> ... glibc: [ on ]
> ... gtk2: [ OFF ]
> ... libaudit: [ OFF ]
> ... libbfd: [ OFF ]
> ... libelf: [ OFF ]
> ... libnuma: [ OFF ]
> ... numa_num_possible_cpus: [ OFF ]
> ... libperl: [ OFF ]
> ... libpython: [ OFF ]
> ... libslang: [ OFF ]
> ... libcrypto: [ OFF ]
> ... libunwind: [ OFF ]
> ... libdw-dwarf-unwind: [ OFF ]
> ... zlib: [ OFF ]
> ... lzma: [ OFF ]
> ... get_cpuid: [ OFF ]
> ... bpf: [ on ]
>
> config/Makefile:260: No libelf found, disables 'probe' tool and BPF support
> in 'perf record', please install elfutils-libelf-devel/libelf-dev
> config/Makefile:413: Disabling post unwind, no support found.
> config/Makefile:459: No libaudit.h found, disables 'trace' tool, please
> install audit-libs-devel or libaudit-dev config/Makefile:470: No
> libcrypto.h found, disables jitted code injection, please install
> libssl-devel or libssl-dev config/Makefile:485: slang not found, disables
> TUI support. Please install slang-devel or libslang-dev
> config/Makefile:499: GTK2 not found, disables GTK2 support. Please install
> gtk2-devel or libgtk2.0-dev config/Makefile:527: Missing perl devel files.
> Disabling perl scripting support, please install
> perl-ExtUtils-Embed/libperl-dev config/Makefile:553: No python interpreter
> was found: disables Python support - please install python-devel/python-dev
> config/Makefile:660: No liblzma found, disables xz kernel module
> decompression, please install xz-devel/liblzma-dev config/Makefile:673: No
> numa.h found, disables 'perf bench numa mem' benchmark, please install
> numactl-devel/libnuma-devel/libnuma-dev config/Makefile:730: Your gcc lacks
> the __get_cpuid() builtin, disables support for auxtrace/Intel PT, please
<snip>
Thanks Arnaldo. Could you document how to specify the sysroot path and
secondary include and library paths?
Also, how can I get more input to debug what is going wrong? So far I tried to
strace make and edit the makefile to add debug output, but with very limited
success. I'm used to CMake, which has both verbose error messages and keeps a
log file around with even more information on what went wrong. Furthermore,
for these kinds of compile checks, I can easily manually reproduce what CMake
did to figure out what is going wrong. With perf's make files, none of this
seems to be easily done :(
Bye
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-06-17 9:49 ` Milian Wolff
@ 2016-06-17 11:00 ` Arnaldo Carvalho de Melo
2016-06-20 1:56 ` Wangnan (F)
0 siblings, 1 reply; 15+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-06-17 11:00 UTC (permalink / raw)
To: Milian Wolff, jiri, Wang Nan, He Kuang; +Cc: linux-perf-users
Adding some folks to the CC list, that either worked on the make
infrastructure or that I know works with cross compiling environments,
maybe they can help.
More below.
Em Fri, Jun 17, 2016 at 11:49:28AM +0200, Milian Wolff escreveu:
> On Donnerstag, 16. Juni 2016 13:11:11 CEST Arnaldo Carvalho de Melo wrote:
> > Em Wed, Jun 15, 2016 at 04:24:52PM +0200, Milian Wolff escreveu:
> > > I'm trying to compile a more modern version of the user-space perf tools
> > > for an arm64 embedded target. So far, no cigar.
> > >
> > > Neither tools/build/Documentation nor tools/perf/Documentation/Build.txt
> > > explain how this should be done. Right now, I'm trying the following from
> > > an SDK with an environment that already sets up CC, CFLAGS etc. pp.
> > >
> > > [SDK] ~/milian/linux/tools/perf$ make ARCH=arm64 CROSS_COMPILE=/home/sdk/
> > > sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux/aarch64-gnu-linux-
> > > CFLAGS="--sysroot=/home/sdk/sysroots/aarch64-gnu-linux
> > > -I/home/milian/target- prefix/include -L/home/milian/target-prefix/lib
> > > $CFLAGS"
> > >
> > > BUILD: Doing 'make -j8' parallel build
> > >
> > > Auto-detecting system features:
> > > ... dwarf: [ OFF ]
> > > ... dwarf_getlocations: [ OFF ]
> > > ... glibc: [ OFF ]
> > > ... gtk2: [ OFF ]
> > > ... libaudit: [ OFF ]
> > > ... libbfd: [ OFF ]
> > > ... libelf: [ OFF ]
> > > ... libnuma: [ OFF ]
> > > ... numa_num_possible_cpus: [ OFF ]
> > > ... libperl: [ OFF ]
> > > ... libpython: [ OFF ]
> > > ... libslang: [ OFF ]
> > > ... libcrypto: [ OFF ]
> > > ... libunwind: [ OFF ]
> > > ... libdw-dwarf-unwind: [ OFF ]
> > > ... zlib: [ OFF ]
> > > ... lzma: [ OFF ]
> > > ... get_cpuid: [ OFF ]
> > > ... bpf: [ OFF ]
> > >
> > > config/Makefile:272: *** No gnu/libc-version.h found, please install
> > > glibc-
> > > dev[el]. Stop
> > >
> > > How can I figure out where perf's buildsystem is looking for the
> > > dependencies? How can I configure it to look into both, my sysroot as
> > > well as a secondary path that contains some additional software I
> > > compiled manually?
> >
> > So, I have these cross build images here:
> >
> > [root@jouet ~]# docker images | grep -- -x-
> > perf-build-minimal-debian-experimental-x-mips64 latest 53b5bb082ace 11
> > weeks ago 595.3 MB perf-build-minimal-debian-experimental-x-mips64el
> > latest 427fa4c1ad0a 11 weeks ago 595.4 MB
> > perf-build-minimal-debian-experimental-x-mipsel latest 1247b61110bf 11
> > weeks ago 589.4 MB perf-build-minimal-ubuntu-x-arm
> > latest cb739975a1f0 11 weeks ago 380.5 MB
> > perf-build-minimal-ubuntu-x-arm64 latest 83fa1b24c6b6 11
> > weeks ago 357.2 MB perf-build-minimal-ubuntu-x-ppc64
> > latest b759a1866191 11 weeks ago 384.3 MB
> > perf-build-minimal-ubuntu-x-ppc64el latest a3f1e718196a 11
> > weeks ago 372.3 MB [root@jouet ~]#
> >
> > But those are minimal builds, without that many devel packages, have
> > to go back looking for multiarch libs in debian, anyway, it works
> > a bit better than what you have experienced:
> >
> > [root@jouet ubuntu-x-arm64]# cat Dockerfile
> > FROM docker.io/ubuntu
> > MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
> > #ENV DEBIAN_FRONTEND noninteractive
> > RUN apt-get update -y
> > RUN apt-get upgrade -y
> > RUN apt-get install -y make gcc-aarch64-linux-gnu flex bison
> > # buildable!
> > # ubuntu doesn't have the other devel packages for arm64, so build just the
> > basic tool RUN mkdir -p /tmp/build/perf
> > ENTRYPOINT make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C
> > /git/linux/tools/perf O=/tmp/build/perf [root@jouet ubuntu-x-arm64]#
> > [root@jouet ubuntu-x-arm64]# docker run -v /home/acme/git:/git:Z --rm=true
> > -t -i perf-build-minimal-ubuntu-x-arm64 make: Entering directory
> > `/git/linux/tools/perf'
> > BUILD: Doing 'make -j4' parallel build
> > sh: 1: command: Illegal option -c
> >
> > Auto-detecting system features:
> > ... dwarf: [ OFF ]
> > ... dwarf_getlocations: [ OFF ]
> > ... glibc: [ on ]
> > ... gtk2: [ OFF ]
> > ... libaudit: [ OFF ]
> > ... libbfd: [ OFF ]
> > ... libelf: [ OFF ]
> > ... libnuma: [ OFF ]
> > ... numa_num_possible_cpus: [ OFF ]
> > ... libperl: [ OFF ]
> > ... libpython: [ OFF ]
> > ... libslang: [ OFF ]
> > ... libcrypto: [ OFF ]
> > ... libunwind: [ OFF ]
> > ... libdw-dwarf-unwind: [ OFF ]
> > ... zlib: [ OFF ]
> > ... lzma: [ OFF ]
> > ... get_cpuid: [ OFF ]
> > ... bpf: [ on ]
> >
> > config/Makefile:260: No libelf found, disables 'probe' tool and BPF support
> > in 'perf record', please install elfutils-libelf-devel/libelf-dev
> > config/Makefile:413: Disabling post unwind, no support found.
> > config/Makefile:459: No libaudit.h found, disables 'trace' tool, please
> > install audit-libs-devel or libaudit-dev config/Makefile:470: No
> > libcrypto.h found, disables jitted code injection, please install
> > libssl-devel or libssl-dev config/Makefile:485: slang not found, disables
> > TUI support. Please install slang-devel or libslang-dev
> > config/Makefile:499: GTK2 not found, disables GTK2 support. Please install
> > gtk2-devel or libgtk2.0-dev config/Makefile:527: Missing perl devel files.
> > Disabling perl scripting support, please install
> > perl-ExtUtils-Embed/libperl-dev config/Makefile:553: No python interpreter
> > was found: disables Python support - please install python-devel/python-dev
> > config/Makefile:660: No liblzma found, disables xz kernel module
> > decompression, please install xz-devel/liblzma-dev config/Makefile:673: No
> > numa.h found, disables 'perf bench numa mem' benchmark, please install
> > numactl-devel/libnuma-devel/libnuma-dev config/Makefile:730: Your gcc lacks
> > the __get_cpuid() builtin, disables support for auxtrace/Intel PT, please
>
> <snip>
>
> Thanks Arnaldo. Could you document how to specify the sysroot path and
> secondary include and library paths?
>
> Also, how can I get more input to debug what is going wrong? So far I tried to
> strace make and edit the makefile to add debug output, but with very limited
> success. I'm used to CMake, which has both verbose error messages and keeps a
> log file around with even more information on what went wrong. Furthermore,
> for these kinds of compile checks, I can easily manually reproduce what CMake
> did to figure out what is going wrong. With perf's make files, none of this
> seems to be easily done :(
Yeah, we're really bad at documenting things, lemme try finding what can
help here:
tools/build/Documentation/Build.txt
tools/perf/Documentation/Build.txt
And in your output dir (O= or in place, in tools/perf/)
[acme@jouet linux]$ ls -la /tmp/build/perf/feature/*.output | tail
-rw-rw-r--. 1 acme acme 0 Jun 16 18:36 /tmp/build/perf/feature/test-libunwind.make.output
-rw-rw-r--. 1 acme acme 0 Jun 16 18:36 /tmp/build/perf/feature/test-libunwind-x86_64.make.output
-rw-rw-r--. 1 acme acme 107 Jun 16 18:41 /tmp/build/perf/feature/test-libunwind-x86.make.output
-rw-rw-r--. 1 acme acme 0 Jun 16 18:36 /tmp/build/perf/feature/test-lzma.make.output
-rw-rw-r--. 1 acme acme 0 Jun 16 18:36 /tmp/build/perf/feature/test-numa_num_possible_cpus.make.output
-rw-rw-r--. 1 acme acme 0 Jun 16 18:36 /tmp/build/perf/feature/test-pthread-attr-setaffinity-np.make.output
-rw-rw-r--. 1 acme acme 0 Jun 16 18:36 /tmp/build/perf/feature/test-stackprotector-all.make.output
-rw-rw-r--. 1 acme acme 0 Jun 16 18:36 /tmp/build/perf/feature/test-sync-compare-and-swap.make.output
-rw-rw-r--. 1 acme acme 0 Jun 16 18:36 /tmp/build/perf/feature/test-timerfd.make.output
-rw-rw-r--. 1 acme acme 0 Jun 16 18:36 /tmp/build/perf/feature/test-zlib.make.output
[acme@jouet linux]$
So, a zero sized file means that feature was detected without a problem, lets
see one that has content:
[acme@jouet linux]$ cat /tmp/build/perf/feature/test-libunwind-x86.make.output
test-libunwind-x86.c:1:27: fatal error: libunwind-x86.h: No such file or directory
compilation terminated.
[acme@jouet linux]$
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-06-17 11:00 ` Arnaldo Carvalho de Melo
@ 2016-06-20 1:56 ` Wangnan (F)
2016-06-27 11:56 ` Milian Wolff
0 siblings, 1 reply; 15+ messages in thread
From: Wangnan (F) @ 2016-06-20 1:56 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Milian Wolff, jiri, He Kuang; +Cc: linux-perf-users
On 2016/6/17 19:00, Arnaldo Carvalho de Melo wrote:
> Adding some folks to the CC list, that either worked on the make
> infrastructure or that I know works with cross compiling environments,
> maybe they can help.
>
> More below.
>
> Em Fri, Jun 17, 2016 at 11:49:28AM +0200, Milian Wolff escreveu:
>> On Donnerstag, 16. Juni 2016 13:11:11 CEST Arnaldo Carvalho de Melo wrote:
>>> Em Wed, Jun 15, 2016 at 04:24:52PM +0200, Milian Wolff escreveu:
>>>> I'm trying to compile a more modern version of the user-space perf tools
>>>> for an arm64 embedded target. So far, no cigar.
>>>>
>>>> Neither tools/build/Documentation nor tools/perf/Documentation/Build.txt
>>>> explain how this should be done. Right now, I'm trying the following from
>>>> an SDK with an environment that already sets up CC, CFLAGS etc. pp.
>>>>
>>>> [SDK] ~/milian/linux/tools/perf$ make ARCH=arm64 CROSS_COMPILE=/home/sdk/
>>>> sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux/aarch64-gnu-linux-
>>>> CFLAGS="--sysroot=/home/sdk/sysroots/aarch64-gnu-linux
>>>> -I/home/milian/target- prefix/include -L/home/milian/target-prefix/lib
>>>> $CFLAGS"
>>>>
>>>> BUILD: Doing 'make -j8' parallel build
>>>>
>>>> Auto-detecting system features:
>>>> ... dwarf: [ OFF ]
>>>> ... dwarf_getlocations: [ OFF ]
>>>> ... glibc: [ OFF ]
>>>> ... gtk2: [ OFF ]
>>>> ... libaudit: [ OFF ]
>>>> ... libbfd: [ OFF ]
>>>> ... libelf: [ OFF ]
>>>> ... libnuma: [ OFF ]
>>>> ... numa_num_possible_cpus: [ OFF ]
>>>> ... libperl: [ OFF ]
>>>> ... libpython: [ OFF ]
>>>> ... libslang: [ OFF ]
>>>> ... libcrypto: [ OFF ]
>>>> ... libunwind: [ OFF ]
>>>> ... libdw-dwarf-unwind: [ OFF ]
>>>> ... zlib: [ OFF ]
>>>> ... lzma: [ OFF ]
>>>> ... get_cpuid: [ OFF ]
>>>> ... bpf: [ OFF ]
>>>>
>>>> config/Makefile:272: *** No gnu/libc-version.h found, please install
>>>> glibc-
>>>> dev[el]. Stop
I think this error message is missleading. Let's see source code:
ifdef NO_LIBELF
...
else
ifeq ($(feature-libelf), 0)
ifeq ($(feature-glibc), 1)
LIBC_SUPPORT := 1
endif
ifeq ($(BIONIC),1)
LIBC_SUPPORT := 1
endif
ifeq ($(LIBC_SUPPORT),1)
...
else
ifneq ($(filter s% -static%,$(LDFLAGS),),)
msg := $(error No static glibc found, please install glibc-static);
else
msg := $(error No gnu/libc-version.h found, please install
glibc-dev[el]);
endif
endif
else
...
endif # libelf support
endif # NO_LIBELF
So the 'libc-version.h' error message really means the failure of
feature-glibc detector.
There's many reasons cause libc detector fail. 'libc-version.h' in error
message provides
wrong clue, lead user to check this file instead of checking feature
check result.
Thank you.
>>>> How can I figure out where perf's buildsystem is looking for the
>>>> dependencies? How can I configure it to look into both, my sysroot as
>>>> well as a secondary path that contains some additional software I
>>>> compiled manually?
>>>
[SNIP]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-06-20 1:56 ` Wangnan (F)
@ 2016-06-27 11:56 ` Milian Wolff
2016-08-03 20:56 ` Milian Wolff
0 siblings, 1 reply; 15+ messages in thread
From: Milian Wolff @ 2016-06-27 11:56 UTC (permalink / raw)
To: wangnan0; +Cc: acme, jiri, hekuang, linux-perf-users
[-- Attachment #1: Type: text/plain, Size: 4168 bytes --]
On Monday, June 20, 2016 9:56:09 AM CEST Wangnan (F) wrote:
> On 2016/6/17 19:00, Arnaldo Carvalho de Melo wrote:
> > Adding some folks to the CC list, that either worked on the make
> > infrastructure or that I know works with cross compiling environments,
> > maybe they can help.
> >
> > More below.
> >
> > Em Fri, Jun 17, 2016 at 11:49:28AM +0200, Milian Wolff escreveu:
> >> On Donnerstag, 16. Juni 2016 13:11:11 CEST Arnaldo Carvalho de Melo
wrote:
> >>> Em Wed, Jun 15, 2016 at 04:24:52PM +0200, Milian Wolff escreveu:
> >>>> I'm trying to compile a more modern version of the user-space perf
> >>>> tools
> >>>> for an arm64 embedded target. So far, no cigar.
> >>>>
> >>>> Neither tools/build/Documentation nor
> >>>> tools/perf/Documentation/Build.txt
> >>>> explain how this should be done. Right now, I'm trying the following
> >>>> from
> >>>> an SDK with an environment that already sets up CC, CFLAGS etc. pp.
> >>>>
> >>>> [SDK] ~/milian/linux/tools/perf$ make ARCH=arm64
> >>>> CROSS_COMPILE=/home/sdk/
> >>>> sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux/aarch64-gnu-linux
> >>>> -
> >>>> CFLAGS="--sysroot=/home/sdk/sysroots/aarch64-gnu-linux
> >>>> -I/home/milian/target- prefix/include -L/home/milian/target-prefix/lib
> >>>> $CFLAGS"
> >>>>
> >>>> BUILD: Doing 'make -j8' parallel build
> >>>>
> >>>> Auto-detecting system features:
> >>>> ... dwarf: [ OFF ]
> >>>> ... dwarf_getlocations: [ OFF ]
> >>>> ... glibc: [ OFF ]
> >>>> ... gtk2: [ OFF ]
> >>>> ... libaudit: [ OFF ]
> >>>> ... libbfd: [ OFF ]
> >>>> ... libelf: [ OFF ]
> >>>> ... libnuma: [ OFF ]
> >>>> ... numa_num_possible_cpus: [ OFF ]
> >>>> ... libperl: [ OFF ]
> >>>> ... libpython: [ OFF ]
> >>>> ... libslang: [ OFF ]
> >>>> ... libcrypto: [ OFF ]
> >>>> ... libunwind: [ OFF ]
> >>>> ... libdw-dwarf-unwind: [ OFF ]
> >>>> ... zlib: [ OFF ]
> >>>> ... lzma: [ OFF ]
> >>>> ... get_cpuid: [ OFF ]
> >>>> ... bpf: [ OFF ]
> >>>>
> >>>> config/Makefile:272: *** No gnu/libc-version.h found, please install
> >>>> glibc-
> >>>> dev[el]. Stop
>
> I think this error message is missleading. Let's see source code:
>
> ifdef NO_LIBELF
> ...
> else
> ifeq ($(feature-libelf), 0)
> ifeq ($(feature-glibc), 1)
> LIBC_SUPPORT := 1
> endif
> ifeq ($(BIONIC),1)
> LIBC_SUPPORT := 1
> endif
> ifeq ($(LIBC_SUPPORT),1)
> ...
> else
> ifneq ($(filter s% -static%,$(LDFLAGS),),)
> msg := $(error No static glibc found, please install glibc-static);
> else
> msg := $(error No gnu/libc-version.h found, please install
> glibc-dev[el]);
> endif
> endif
> else
> ...
> endif # libelf support
> endif # NO_LIBELF
>
> So the 'libc-version.h' error message really means the failure of
> feature-glibc detector.
> There's many reasons cause libc detector fail. 'libc-version.h' in error
> message provides
> wrong clue, lead user to check this file instead of checking feature
> check result.
OK, so if it's the wrong clue, can you tell me what else to look at then?
I'm seeing
$ echo $CC
aarch64-gnu-linux-gcc --sysroot=/home/yocto/SDK/E013/sdk/sysroots/aarch64-gnu-
linux
$ echo $PWD
path/to/linux/tools/build/feature
$ $CC test-glib.c
$ echo $?
0
The above looks good, but from a make run I get:
$ cat test-glibc.make.output
test-glibc.c:1:20: fatal error: stdlib.h: No such file or directory
#include <stdlib.h>
^
compilation terminated.
Can I somehow figure out how it tries to compile the test-glib.c file? I.e.
can I invoke "make" in a verbose mode that outputs all commands?
Thanks
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-06-15 15:47 ` Kim Phillips
@ 2016-06-27 11:56 ` Milian Wolff
0 siblings, 0 replies; 15+ messages in thread
From: Milian Wolff @ 2016-06-27 11:56 UTC (permalink / raw)
To: kim.phillips; +Cc: linux-perf-users
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
On Wednesday, June 15, 2016 10:47:06 AM CEST Kim Phillips wrote:
> On Wed, 15 Jun 2016 16:24:52 +0200
>
> Milian Wolff <milian.wolff@kdab.com> wrote:
> > I'm trying to compile a more modern version of the user-space perf tools
> > for an arm64 embedded target. So far, no cigar.
>
> ...
>
> > config/Makefile:272: *** No gnu/libc-version.h found, please install
> > glibc-
> > dev[el]. Stop
>
> fwiw, I've had marginally greater success in the past by perfoming an
> arm64-cross 'make defconfig; make -C tools/perf clean perf' before
> switching to building fully-featured perfs natively.
Doing these steps lead me to the same erroneous output as before.
Thanks
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-06-27 11:56 ` Milian Wolff
@ 2016-08-03 20:56 ` Milian Wolff
2016-08-04 13:22 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 15+ messages in thread
From: Milian Wolff @ 2016-08-03 20:56 UTC (permalink / raw)
To: wangnan0; +Cc: acme, jiri, hekuang, linux-perf-users
[-- Attachment #1: Type: text/plain, Size: 10615 bytes --]
On Montag, 27. Juni 2016 13:56:23 CEST Milian Wolff wrote:
> On Monday, June 20, 2016 9:56:09 AM CEST Wangnan (F) wrote:
> > On 2016/6/17 19:00, Arnaldo Carvalho de Melo wrote:
> > > Adding some folks to the CC list, that either worked on the make
> > > infrastructure or that I know works with cross compiling environments,
> > > maybe they can help.
> > >
> > > More below.
> > >
> > > Em Fri, Jun 17, 2016 at 11:49:28AM +0200, Milian Wolff escreveu:
> > >> On Donnerstag, 16. Juni 2016 13:11:11 CEST Arnaldo Carvalho de Melo
>
> wrote:
> > >>> Em Wed, Jun 15, 2016 at 04:24:52PM +0200, Milian Wolff escreveu:
> > >>>> I'm trying to compile a more modern version of the user-space perf
> > >>>> tools
> > >>>> for an arm64 embedded target. So far, no cigar.
> > >>>>
> > >>>> Neither tools/build/Documentation nor
> > >>>> tools/perf/Documentation/Build.txt
> > >>>> explain how this should be done. Right now, I'm trying the following
> > >>>> from
> > >>>> an SDK with an environment that already sets up CC, CFLAGS etc. pp.
> > >>>>
> > >>>> [SDK] ~/milian/linux/tools/perf$ make ARCH=arm64
> > >>>> CROSS_COMPILE=/home/sdk/
> > >>>> sysroots/x86_64-oesdk-linux/usr/bin/aarch64-gnu-linux/aarch64-gnu-lin
> > >>>> ux
> > >>>> -
> > >>>> CFLAGS="--sysroot=/home/sdk/sysroots/aarch64-gnu-linux
> > >>>> -I/home/milian/target- prefix/include
> > >>>> -L/home/milian/target-prefix/lib
> > >>>> $CFLAGS"
> > >>>>
> > >>>> BUILD: Doing 'make -j8' parallel build
> > >>>>
> > >>>> Auto-detecting system features:
> > >>>> ... dwarf: [ OFF ]
> > >>>> ... dwarf_getlocations: [ OFF ]
> > >>>> ... glibc: [ OFF ]
> > >>>> ... gtk2: [ OFF ]
> > >>>> ... libaudit: [ OFF ]
> > >>>> ... libbfd: [ OFF ]
> > >>>> ... libelf: [ OFF ]
> > >>>> ... libnuma: [ OFF ]
> > >>>> ... numa_num_possible_cpus: [ OFF ]
> > >>>> ... libperl: [ OFF ]
> > >>>> ... libpython: [ OFF ]
> > >>>> ... libslang: [ OFF ]
> > >>>> ... libcrypto: [ OFF ]
> > >>>> ... libunwind: [ OFF ]
> > >>>> ... libdw-dwarf-unwind: [ OFF ]
> > >>>> ... zlib: [ OFF ]
> > >>>> ... lzma: [ OFF ]
> > >>>> ... get_cpuid: [ OFF ]
> > >>>> ... bpf: [ OFF ]
> > >>>>
> > >>>> config/Makefile:272: *** No gnu/libc-version.h found, please install
> > >>>> glibc-
> > >>>> dev[el]. Stop
> >
> > I think this error message is missleading. Let's see source code:
> >
> > ifdef NO_LIBELF
> >
> > ...
> >
> > else
> >
> > ifeq ($(feature-libelf), 0)
> >
> > ifeq ($(feature-glibc), 1)
> >
> > LIBC_SUPPORT := 1
> >
> > endif
> > ifeq ($(BIONIC),1)
> >
> > LIBC_SUPPORT := 1
> >
> > endif
> > ifeq ($(LIBC_SUPPORT),1)
> >
> > ...
> >
> > else
> >
> > ifneq ($(filter s% -static%,$(LDFLAGS),),)
> >
> > msg := $(error No static glibc found, please install
> > glibc-static);
> >
> > else
> >
> > msg := $(error No gnu/libc-version.h found, please install
> >
> > glibc-dev[el]);
> >
> > endif
> >
> > endif
> >
> > else
> >
> > ...
> >
> > endif # libelf support
> >
> > endif # NO_LIBELF
> >
> > So the 'libc-version.h' error message really means the failure of
> > feature-glibc detector.
> > There's many reasons cause libc detector fail. 'libc-version.h' in error
> > message provides
> > wrong clue, lead user to check this file instead of checking feature
> > check result.
>
> OK, so if it's the wrong clue, can you tell me what else to look at then?
>
> I'm seeing
>
> $ echo $CC
> aarch64-gnu-linux-gcc
> --sysroot=/home/yocto/SDK/E013/sdk/sysroots/aarch64-gnu- linux
> $ echo $PWD
> path/to/linux/tools/build/feature
> $ $CC test-glib.c
> $ echo $?
> 0
>
> The above looks good, but from a make run I get:
>
> $ cat test-glibc.make.output
> test-glibc.c:1:20: fatal error: stdlib.h: No such file or directory
> #include <stdlib.h>
> ^
> compilation terminated.
>
> Can I somehow figure out how it tries to compile the test-glib.c file? I.e.
> can I invoke "make" in a verbose mode that outputs all commands?
I have finally found the time to dig into these issues and now found a way to
cross compile perf for my target platform. Here are the issues I needed to
overcome:
a) CC can only point to the executable
For some reason, the toolchain I have to work with defines
CC=aarch64-gnu-linux-gcc --sysroot=/home/yocto/SDK/E013/sdk/sysroots/aarch64-
gnu-linux
CFLAGS=-O2 -pipe -g -feliminate-unused-debug-types -fno-omit-frame-pointer -
march=armv8-a -funwind-tables
This works everywhere else (qmake, configure, cmake), but the kernel
buildsystem is more picky and will silently ignore the sysroot parameter set
in CC. To fix this, one has to move the sysroot parameter into CFLAGS. This
was the reason for the "test-glib.c" feature failure
b) Manually enable/disable features
Once the above is fixed, the feature detection is still completely broken for
me. It seems to blindly enable all features for some reason:
~~~~~~~~~~~~~
export CC="aarch64-gnu-linux-gcc"
export CFLAGS="--sysroot=/home/yocto/SDK/E013/sdk/sysroots/aarch64-gnu-linux -
O2 -pipe -g -feliminate-unused-debug-types -fno-omit-frame-pointer -
march=armv8-a -funwind-tables"
export ARCH=arm64
export CROSS_COMPILE=aarch64-gnu-linux-
make V=1 VF=1 EXTRA_CFLAGS="$CFLAGS"
BUILD: Doing 'make -j8' parallel build
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... gtk2: [ on ]
... libaudit: [ on ]
... libbfd: [ on ]
... libelf: [ on ]
... libnuma: [ on ]
... numa_num_possible_cpus: [ on ]
... libperl: [ on ]
... libpython: [ on ]
... libslang: [ on ]
... libcrypto: [ on ]
... libunwind: [ on ]
... libdw-dwarf-unwind: [ on ]
... zlib: [ on ]
... lzma: [ on ]
... get_cpuid: [ on ]
... bpf: [ on ]
... backtrace: [ on ]
... fortify-source: [ on ]
... sync-compare-and-swap: [ on ]
... gtk2-infobar: [ on ]
... libelf-getphdrnum: [ on ]
... libelf-gelf_getnote: [ on ]
... libelf-getshdrstrndx: [ on ]
... libelf-mmap: [ on ]
... libpython-version: [ on ]
... libunwind-x86: [ on ]
... libunwind-x86_64: [ on ]
... libunwind-arm: [ on ]
... libunwind-aarch64: [ on ]
... pthread-attr-setaffinity-np: [ on ]
... stackprotector-all: [ on ]
... timerfd: [ on ]
... sdt: [ on ]
<snip>
In file included from /home/yocto/milian/linux/tools/perf/util/include/../../
ui/keysyms.h:4:0,
from /home/yocto/milian/linux/tools/perf/util/include/../
hist.h:409,
from /home/yocto/milian/linux/tools/perf/util/include/../
sort.h:23,
from ui/gtk/browser.c:4:
/home/yocto/milian/linux/tools/perf/util/include/../../ui/libslang.h:12:19:
fatal error: slang.h: No such file or directory
#include <slang.h>
... and many more errors
~~~~~~~~~~~~~
Looking at the faulty FEATURE-DUMP file in tools/build, I noticed not only
features being enabled that I have on my host but not on the target (which
would be bad enough), but also the following, which can only mean it blindly
enabled everything:
~~~~~~~~~~~~~~
feature-libunwind=1
feature-libunwind-x86=1
feature-libunwind-x86_64=1
feature-libunwind-arm=1
feature-libunwind-aarch64=1
~~~~~~~~~~~~~~
I work-arounded this for now by copying the faulty FEATURE-DUMP file from
tools/build/ to some other location, then hand-editing it to disable the
features that I know are not available for my platform (slang, sdt, numa, gtk,
x86 libunwind, ...). Then, I pass FEATURES_DUMP=path/to/my/FEATURE-DUMP to
make.
c) Picking up dependencies from custom prefix
I've build libelf and other dependencies manually into a custom prefix outside
of my sysroot. To pick those up, it's not enough to pass `prefix=path/to/
prefix` to make. You need to manually add `-Ipath/to/prefix/include` to
EXTRA_CFLAGS and `-Lpath/to/prefix/lib` to LDFLAGS...
d) My final make invocation looks like this now:
export CC=aarch64-gnu-linux-gcc
export CFLAGS="--sysroot=/home/yocto/SDK/E013/sdk/sysroots/aarch64-gnu-linux
-O2 -pipe -g -feliminate-unused-debug-types -fno-omit-frame-pointer -
march=armv8-a -funwind-tables"
make \
FEATURES_DUMP=/home/yocto/milian/perf-FEATURE-DUMP \
CROSS_COMPILE="aarch64-gnu-linux-" \
EXTRA_CFLAGS="$CFLAGS -I/home/yocto/milian/target-prefix/include" \
LDFLAGS="-L/home/yocto/milian/target-prefix/lib $LDFLAGS" \
prefix=/home/yocto/milian/target-prefix
The features dump contains the following:
feature-backtrace=1
feature-dwarf=1
feature-dwarf_getlocations=1
feature-fortify-source=1
feature-sync-compare-and-swap=1
feature-glibc=1
feature-gtk2=0
feature-gtk2-infobar=0
feature-libaudit=0
feature-libbfd=0
feature-libelf=1
feature-libelf-getphdrnum=1
feature-libelf-gelf_getnote=1
feature-libelf-getshdrstrndx=1
feature-libelf-mmap=1
feature-libnuma=0
feature-numa_num_possible_cpus=0
feature-libperl=0
feature-libpython=0
feature-libpython-version=0
feature-libslang=0
feature-libcrypto=1
feature-libunwind=1
feature-libunwind-x86=0
feature-libunwind-x86_64=0
feature-libunwind-arm=1
feature-libunwind-aarch64=1
feature-pthread-attr-setaffinity-np=1
feature-stackprotector-all=1
feature-timerfd=1
feature-libdw-dwarf-unwind=1
feature-zlib=1
feature-lzma=1
feature-get_cpuid=1
feature-bpf=0
feature-sdt=0
I hope this helps others. I finally have a working up2date perf on my aarch64
platform and it seems to work form my simple 5min tests so far.
Cheers
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-08-03 20:56 ` Milian Wolff
@ 2016-08-04 13:22 ` Arnaldo Carvalho de Melo
2016-08-04 15:02 ` Milian Wolff
0 siblings, 1 reply; 15+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-08-04 13:22 UTC (permalink / raw)
To: Milian Wolff; +Cc: wangnan0, jiri, hekuang, linux-perf-users
Em Wed, Aug 03, 2016 at 10:56:20PM +0200, Milian Wolff escreveu:
> I hope this helps others. I finally have a working up2date perf on my aarch64
> platform and it seems to work form my simple 5min tests so far.
Ok, that should help people, but it is way convoluted :-\
How did you obtained your cross compiler environment? Some ready made
tarball or set of distro packages? I have an ever growing set of perf
build cointainers that includes a few cross compilers:
[root@jouet tmp]# time dm
1: alpine:3.4: Ok
2: android-ndk:r12b: Ok
3: archlinux:latest: Ok
4: centos:5: Ok
5: centos:6: Ok
6: centos:7: Ok
7: debian:7: Ok
8: debian:8: Ok
9: debian:experimental: Ok
10: fedora:20: Ok
11: fedora:21: Ok
12: fedora:22: Ok
13: fedora:23: Ok
14: fedora:24: Ok
15: fedora:rawhide: Ok
16: mageia:5: Ok
17: opensuse:13.2: Ok
18: opensuse:42.1: Ok
19: ubuntu:14.04.4: Ok
20: ubuntu:15.10: Ok
21: ubuntu:16.04: Ok
22: ubuntu:16.04-x-arm64: Ok
23: ubuntu:16.04-x-armhf: Ok
24: ubuntu:16.04-x-powerpc64: Ok
25: ubuntu:16.04-x-powerpc64el: Ok
26: ubuntu:16.04-x-s390: Ok
real 15m53.494s
user 0m1.258s
sys 0m0.928s
[root@jouet tmp]#
The android-ndk:r12b and the ubuntu:16.04-x-* ones are all cross compiler
environments, some need first cross building zlib and libelf, since those are
not pre-packaged, just the base libc, etc ones are, for instance, the one that
generates an aarch64 perf is:
[root@jouet x-arm64]# cat /root/perf/ubuntu/16.04/x-arm64/Dockerfile
# docker.io/acmel/linux-perf-tools-build-ubuntu:16.04-x-arm64
FROM docker.io/ubuntu:16.04
MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
#ENV DEBIAN_FRONTEND noninteractive
# ubuntu doesn't have the other devel packages for arm64, so build just the basic tool
# libelf-dev is needed to build objtool, which is a host tool, not being cross compiled.
# It will check the cross compiled kernel objects
# It will not be used tho, as there is no support to check aarch64 binaries yet
RUN apt-get -y update && \
apt-get install -y make gcc-aarch64-linux-gnu flex bison && \
apt-get clean && \
rm -rf /usr/share/doc /usr/share/gtk-doc && \
mkdir -m 777 -p /tmp/build/perf /tmp/build/objtool && \
groupadd -r perfbuilder && \
useradd -r -g perfbuilder perfbuilder
RUN apt-get -y install wget bzip2 && \
export TARGET=aarch64-linux-gnu && \
export INSTALLDIR=/usr/${TARGET} && \
export PATH=$INSTALLDIR/bin:$PATH && \
export TARGETMACH=${TARGET} && \
export CROSS=${TARGET}- && \
export CC=${CROSS}gcc && \
export LD=${CROSS}ld && \
export AS=${CROSS}as && \
wget -q http://zlib.net/zlib-1.2.8.tar.gz && \
wget -q https://fedorahosted.org/releases/e/l/elfutils/0.166/elfutils-0.166.tar.bz2 && \
tar xf zlib-1.2.8.tar.gz && \
cd zlib-1.2.8 && \
./configure --prefix=${INSTALLDIR} && \
make && \
make install && \
cd .. && \
rm -rf zlib-1.2.8 && \
rm -f zlib-1.2.8.tar.gz && \
tar xf elfutils-0.166.tar.bz2 && \
cd elfutils-0.166 && \
./configure --host=${TARGET} --prefix=${INSTALLDIR} && \
make && \
make install && \
cd .. && \
rm -rf elfutils-0.166 && \
apt-get -y remove wget bzip2 && \
apt-get clean && \
unset TARGET INSTALLDIR TARGETMACH CROSS CC LD AS
USER perfbuilder
ENTRYPOINT make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C /git/linux/tools/perf O=/tmp/build/perf
# There is no support yet for checking aarch64 binaries, only x86_64 ones
# make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C /git/linux/tools/objtool O=/tmp/build/objtool
[root@jouet x-arm64]#
- Arnaldo
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-08-04 13:22 ` Arnaldo Carvalho de Melo
@ 2016-08-04 15:02 ` Milian Wolff
2016-08-04 18:36 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 15+ messages in thread
From: Milian Wolff @ 2016-08-04 15:02 UTC (permalink / raw)
To: acme; +Cc: wangnan0, jiri, hekuang, linux-perf-users
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]
On Thursday, August 4, 2016 10:22:25 AM CEST Arnaldo Carvalho de Melo wrote:
> Em Wed, Aug 03, 2016 at 10:56:20PM +0200, Milian Wolff escreveu:
> > I hope this helps others. I finally have a working up2date perf on my
> > aarch64 platform and it seems to work form my simple 5min tests so far.
>
> Ok, that should help people, but it is way convoluted :-\
>
> How did you obtained your cross compiler environment? Some ready made
> tarball or set of distro packages? I have an ever growing set of perf
> build cointainers that includes a few cross compilers:
The environment was provided to us as a tarball from a customer of ours, who
probably got that from another subcontractor.
<snip>
export INSTALLDIR=/usr/${TARGET} && \
^-- is that path potentially special cased in the build file? I mean you don't
set the sysroot anywhere, nor do you seem to pass special include paths to
perf. This of course works fine in a docker environment, but for "normal"
development machines, where you compile and install stuff somewhere in $HOME,
this won't work at all.
The above wouldn't directly explain the really strange behavior of the feature
detection though (which enables _everything_ for me).
Bye
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-08-04 15:02 ` Milian Wolff
@ 2016-08-04 18:36 ` Arnaldo Carvalho de Melo
2016-08-04 21:58 ` Milian Wolff
0 siblings, 1 reply; 15+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-08-04 18:36 UTC (permalink / raw)
To: Milian Wolff; +Cc: wangnan0, jiri, hekuang, linux-perf-users
Em Thu, Aug 04, 2016 at 05:02:01PM +0200, Milian Wolff escreveu:
> On Thursday, August 4, 2016 10:22:25 AM CEST Arnaldo Carvalho de Melo wrote:
> > Em Wed, Aug 03, 2016 at 10:56:20PM +0200, Milian Wolff escreveu:
> > > I hope this helps others. I finally have a working up2date perf on my
> > > aarch64 platform and it seems to work form my simple 5min tests so far.
> >
> > Ok, that should help people, but it is way convoluted :-\
> >
> > How did you obtained your cross compiler environment? Some ready made
> > tarball or set of distro packages? I have an ever growing set of perf
> > build cointainers that includes a few cross compilers:
>
> The environment was provided to us as a tarball from a customer of ours, who
> probably got that from another subcontractor.
>
> <snip>
>
> export INSTALLDIR=/usr/${TARGET} && \
>
> ^-- is that path potentially special cased in the build file? I mean you don't
Huh? Not that I am aware, no, I just looked at where the existing cross
build packages were located, so that I used the same place for the cross
built versions of libelf and zlib:
[root@jouet x-arm64]# docker run --entrypoint=/bin/bash -v /home/acme/git:/git:Z --rm -ti docker.io/acmel/linux-perf-tools-build-ubuntu:16.04-x-arm64
perfbuilder@122a2cb948d6:/$
perfbuilder@122a2cb948d6:/$ dpkg -L libc6-dev-arm64-cross | tail
/usr/aarch64-linux-gnu/lib/libnss_nis.so
/usr/aarch64-linux-gnu/lib/libnss_nisplus.so
/usr/aarch64-linux-gnu/lib/libnss_files.so
/usr/aarch64-linux-gnu/lib/libdl.so
/usr/aarch64-linux-gnu/lib/libcidn.so
/usr/aarch64-linux-gnu/lib/libthread_db.so
/usr/aarch64-linux-gnu/lib/librt.so
/usr/aarch64-linux-gnu/lib/libnss_compat.so
/usr/aarch64-linux-gnu/lib/libanl.so
/usr/aarch64-linux-gnu/lib/libnss_dns.so
perfbuilder@122a2cb948d6:/$
That is the same as all the other devel packages with the arm64-cross on ubuntu
16.04:
perfbuilder@122a2cb948d6:/$ dpkg -l | grep arm64-cross
ii libasan2-arm64-cross 5.4.0-6ubuntu1~16.04.1cross1 all AddressSanitizer -- a fast memory error detector
ii libatomic1-arm64-cross 5.4.0-6ubuntu1~16.04.1cross1 all support library providing __atomic built-in functions
ii libc6-arm64-cross 2.23-0ubuntu3cross1 all GNU C Library: Shared libraries (for cross-compiling)
ii libc6-dev-arm64-cross 2.23-0ubuntu3cross1 all GNU C Library: Development Libraries and Header Files (for cross-compiling)
ii libgcc-5-dev-arm64-cross 5.4.0-6ubuntu1~16.04.1cross1 all GCC support library (development files)
ii libgcc1-arm64-cross 1:5.4.0-6ubuntu1~16.04.1cross1 all GCC support library
ii libgomp1-arm64-cross 5.4.0-6ubuntu1~16.04.1cross1 all GCC OpenMP (GOMP) support library
ii libitm1-arm64-cross 5.4.0-6ubuntu1~16.04.1cross1 all GNU Transactional Memory Library
ii libstdc++6-arm64-cross 5.4.0-6ubuntu1~16.04.1cross1 all GNU Standard C++ Library v3
ii libubsan0-arm64-cross 5.4.0-6ubuntu1~16.04.1cross1 all UBSan -- undefined behaviour sanitizer (runtime)
ii linux-libc-dev-arm64-cross 4.4.0-18.34cross1 all Linux Kernel Headers for development (for cross-compiling)
perfbuilder@122a2cb948d6:/$
perfbuilder@122a2cb948d6:/$ dpkg -L libasan2-arm64-cross | grep \.so\.[0-9]
/usr/aarch64-linux-gnu/lib/libasan.so.2.0.0
/usr/aarch64-linux-gnu/lib/libasan.so.2
perfbuilder@122a2cb948d6:/$
perfbuilder@122a2cb948d6:/$ dpkg -L libstdc++6-arm64-cross | grep \.so\.[0-9]
/usr/share/gdb/auto-load/usr/aarch64-linux-gnu/lib/libstdc++.so.6.0.21-gdb.py
/usr/aarch64-linux-gnu/lib/libstdc++.so.6.0.21
/usr/aarch64-linux-gnu/lib/libstdc++.so.6
perfbuilder@122a2cb948d6:/$
etc. So I assumed the best place to install the zlib and libelf devel files was
with that path prefix.
See it running:
# docker run -v /home/acme/git:/git:Z --rm -ti docker.io/acmel/linux-perf-tools-build-ubuntu:16.04-x-arm64
make: Entering directory '/git/linux/tools/perf'
BUILD: Doing 'make -j4' parallel build
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... gtk2: [ OFF ]
... libaudit: [ OFF ]
... libbfd: [ OFF ]
... libelf: [ on ]
... libnuma: [ OFF ]
... numa_num_possible_cpus: [ OFF ]
... libperl: [ OFF ]
... libpython: [ OFF ]
... libslang: [ OFF ]
... libcrypto: [ OFF ]
... libunwind: [ OFF ]
... libdw-dwarf-unwind: [ on ]
... zlib: [ on ]
... lzma: [ OFF ]
... get_cpuid: [ OFF ]
... bpf: [ on ]
Makefile.config:349: BPF prologue is not supported by architecture arm64, missing regs_query_register_offset()
Makefile.config:360: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:406: No libunwind found. Please install libunwind-dev[el] >= 1.1 and/or set LIBUNWIND_DIR
Makefile.config:433: Disabling post unwind, no support found.
Makefile.config:479: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev
Makefile.config:490: No libcrypto.h found, disables jitted code injection, please install libssl-devel or libssl-dev
Makefile.config:505: slang not found, disables TUI support. Please install slang-devel, libslang-dev or libslang2-dev
Makefile.config:519: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev
Makefile.config:547: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev
Makefile.config:573: No python interpreter was found: disables Python support - please install python-devel/python-dev
Makefile.config:651: No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static/libiberty-dev to gain symbol demangling
Makefile.config:680: No liblzma found, disables xz kernel module decompression, please install xz-devel/liblzma-dev
Makefile.config:693: No numa.h found, disables 'perf bench numa mem' benchmark, please install numactl-devel/libnuma-devel/libnuma-dev
Makefile.config:750: Your gcc lacks the __get_cpuid() builtin, disables support for auxtrace/Intel PT, please install a newer gcc
GEN /tmp/build/perf/common-cmds.h
MKDIR /tmp/build/perf/fd/
CC /tmp/build/perf/event-parse.o
CC /tmp/build/perf/fd/array.o
<SNIP>
----------------------
See? The features it is finding are just the ones related to having glibc, zlib
and libelf devel packages that can be used in a cross build.
> set the sysroot anywhere, nor do you seem to pass special include paths to
> perf. This of course works fine in a docker environment, but for "normal"
> development machines, where you compile and install stuff somewhere in $HOME,
> this won't work at all.
Hey, a "docker environment" should be no different than a "normal" development
machine, it should work just the same, its just the former will run inside a
container, but the packages are the same I would install in my workstation if I
wanted to pollute it with a cross compiler environment. Since I want to install
tons of cross compiler environments, I better use some sort of container,
docker being the most popular, I picked it.
> The above wouldn't directly explain the really strange behavior of the feature
> detection though (which enables _everything_ for me).
That is strage, yes, and I haven't even tried to figure out why this
happens in your case, I was just trying to show cross compiler
environments where the cross build of perf works, perhaps that would
help you figure out your specific case.
Further example, here is the Android NDK one, that is on top of Fedora 24
instead of the previous example, that is on top of Ubuntu 16.04, and here you
may have your answer, i.e. use EXTRA_CFLAGS to set --sysroot, I got that from
tools/perf/Documentation/android.txt:
[root@jouet x-arm64]# cat /root/perf/android/r12b/arm/Dockerfile
# docker.io/acmel/linux-perf-tools-build-android-ndk:r12b
FROM docker.io/fedora:24
MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
ENV SOURCEFILE=android-ndk-r12b-linux-x86_64.zip
RUN dnf -y install make bison flex unzip && \
dnf -y clean all && \
mkdir -m 777 -p /tmp/build/perf /tmp/build/objtool && \
curl -OL http://dl.google.com/android/repository/${SOURCEFILE} && \
unzip -d /opt ${SOURCEFILE} && \
rm -f ${SOURCEFILE} && \
rm -rf /opt/android-ndk-r12b/sources \
/opt/android-ndk-r12b/platforms/android-[19]* \
/opt/android-ndk-r12b/platforms/android-2[0-3]* \
/opt/android-ndk-r12b/platforms/android-24/arch-mips* \
/opt/android-ndk-r12b/platforms/android-24/arch-x86* \
/opt/android-ndk-r12b/toolchains/x86* \
/opt/android-ndk-r12b/toolchains/mips* \
/opt/android-ndk-r12b/toolchains/llvm* \
/opt/android-ndk-r12b/prebuilt/ \
/opt/android-ndk-r12b/python* \
/opt/android-ndk-r12b/shader-tools/ &&\
groupadd -r perfbuilder && \
useradd -r -g perfbuilder perfbuilder
USER perfbuilder
ENV NDK=/opt/android-ndk-r12b/
ENV NDK_TOOLCHAIN=${NDK}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-
ENV NDK_SYSROOT=${NDK}/platforms/android-24/arch-arm
ENTRYPOINT make -C /git/linux/tools/perf O=/tmp/build/perf WERROR=0 ARCH=arm CROSS_COMPILE=${NDK_TOOLCHAIN} EXTRA_CFLAGS="-pie --sysroot=${NDK_SYSROOT}" && \
make -C /git/linux/tools/objtool O=/tmp/build/objtool WERROR=0 ARCH=arm CROSS_COMPILE=${NDK_TOOLCHAIN} EXTRA_CFLAGS="-pie --sysroot=${NDK_SYSROOT}"
[root@jouet x-arm64]#
--------------------------------------------------------
This one comes with a bit more pre-built devel packages, so did not have to
cross build zlib (I'll copy the cross build of libelf to get a bit more code
tested...) instead I threw away lots of toolchains for arches I didn't want,
leaving just the ones for "arm-linux-androideabi-", running it we get:
[root@jouet ~]# docker run -v /home/acme/git:/git:Z --rm -ti docker.io/acmel/linux-perf-tools-build-android-ndk:r12b
make: Entering directory '/git/linux/tools/perf'
BUILD: Doing 'make -j4' parallel build
Auto-detecting system features:
... dwarf: [ OFF ]
... dwarf_getlocations: [ OFF ]
... glibc: [ OFF ]
... gtk2: [ OFF ]
... libaudit: [ OFF ]
... libbfd: [ OFF ]
... libelf: [ OFF ]
... libnuma: [ OFF ]
... numa_num_possible_cpus: [ OFF ]
... libperl: [ OFF ]
... libpython: [ OFF ]
... libslang: [ OFF ]
... libcrypto: [ OFF ]
... libunwind: [ OFF ]
... libdw-dwarf-unwind: [ OFF ]
... zlib: [ on ]
... lzma: [ OFF ]
... get_cpuid: [ OFF ]
... bpf: [ OFF ]
Makefile.config:260: No libelf found, disables 'probe' tool and BPF support in 'perf record', please install libelf-dev, libelf-devel or elfutils-libelf-devel
Makefile.config:360: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:433: Disabling post unwind, no support found.
Makefile.config:479: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev
Makefile.config:490: No libcrypto.h found, disables jitted code injection, please install libssl-devel or libssl-dev
Makefile.config:505: slang not found, disables TUI support. Please install slang-devel, libslang-dev or libslang2-dev
Makefile.config:519: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev
- Arnaldo
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-08-04 18:36 ` Arnaldo Carvalho de Melo
@ 2016-08-04 21:58 ` Milian Wolff
2016-08-05 0:13 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 15+ messages in thread
From: Milian Wolff @ 2016-08-04 21:58 UTC (permalink / raw)
To: acme, hekuang; +Cc: wangnan0, linux-perf-users
[-- Attachment #1: Type: text/plain, Size: 8207 bytes --]
On Donnerstag, 4. August 2016 15:36:05 CEST Arnaldo Carvalho de Melo wrote:
> Em Thu, Aug 04, 2016 at 05:02:01PM +0200, Milian Wolff escreveu:
> > On Thursday, August 4, 2016 10:22:25 AM CEST Arnaldo Carvalho de Melo
wrote:
> > > Em Wed, Aug 03, 2016 at 10:56:20PM +0200, Milian Wolff escreveu:
> > > > I hope this helps others. I finally have a working up2date perf on my
> > > > aarch64 platform and it seems to work form my simple 5min tests so
> > > > far.
> > >
> > > Ok, that should help people, but it is way convoluted :-\
> > >
> > > How did you obtained your cross compiler environment? Some ready made
> > > tarball or set of distro packages? I have an ever growing set of perf
> >
> > > build cointainers that includes a few cross compilers:
> > The environment was provided to us as a tarball from a customer of ours,
> > who probably got that from another subcontractor.
> >
> > <snip>
> >
> > export INSTALLDIR=/usr/${TARGET} && \
> >
> > ^-- is that path potentially special cased in the build file? I mean you
> > don't
> Huh? Not that I am aware, no, I just looked at where the existing cross
> build packages were located, so that I used the same place for the cross
> built versions of libelf and zlib:
<snip>
> etc. So I assumed the best place to install the zlib and libelf devel files
> was with that path prefix.
Right, I think my point above was not clear: Since you essentially put your
custom libelf into the implicit sysroot and also don't specify any prefix to
install to, it seems to work out of the box. Is this the common way people
build perf? From my experience working on e.g. KDE, one often has the sysroot
(e.g. /usr), and then a bunch of custom stuff in a prefix somewhere in $HOME.
Doing that with perf seems to be "hard", as it's not enough to do
make prefix=$HOME/path/to/foo
but instead one also needs to pass `-I.../include` and `-L.../lib` to
EXTRA_CFLAGS & LDFLAGS. I'd be willing to supply a patch to simplify this
process, if you think that is acceptable.
> See it running:
<snip>
> See? The features it is finding are just the ones related to having glibc,
> zlib and libelf devel packages that can be used in a cross build.
OK, good to know. Then this clearly is something else special to my setup,
similar to my initial problems with `--sysroot` being defined in `CC` rather
than `EXTRA_CFLAGS`. I'll try to dig into that eventually.
> > set the sysroot anywhere, nor do you seem to pass special include paths to
> > perf. This of course works fine in a docker environment, but for "normal"
> > development machines, where you compile and install stuff somewhere in
> > $HOME, this won't work at all.
>
> Hey, a "docker environment" should be no different than a "normal"
> development machine, it should work just the same, its just the former will
> run inside a container, but the packages are the same I would install in my
> workstation if I wanted to pollute it with a cross compiler environment.
> Since I want to install tons of cross compiler environments, I better use
> some sort of container, docker being the most popular, I picked it.
My point here is exactly the pollution that happens in my non-containered
environment. There, I have tons of dev packages installed in e.g. /usr, which
may potentially get picked up, as well as the "actual" stuff that should be
used from the sysroot. But, again, at this point this is just speculation.
If you have the time, could you try to install some more x86 dev packages in
your docker environments? E.g. when you install libunwind(-x86-64) - does it
then get picked up by your arm cross compile, or does it work as it should?
That data point would help me figure out what could go wrong.
> > The above wouldn't directly explain the really strange behavior of the
> > feature detection though (which enables _everything_ for me).
>
> That is strage, yes, and I haven't even tried to figure out why this
> happens in your case, I was just trying to show cross compiler
> environments where the cross build of perf works, perhaps that would
> help you figure out your specific case.
Yep, it does help (see above). Thanks!
> Further example, here is the Android NDK one, that is on top of Fedora 24
> instead of the previous example, that is on top of Ubuntu 16.04, and here
> you may have your answer, i.e. use EXTRA_CFLAGS to set --sysroot, I got
> that from tools/perf/Documentation/android.txt:
I do pass --sysroot to EXTRA_CFLAGS via CFLAGS. From my previous mail:
export CFLAGS="--sysroot=...
# ^-- CFLAGS contains --sysroot
make ...\
EXTRA_CFLAGS="$CFLAGS -I/home/yocto/milian/target-prefix/include" \
# ^--- and gets passed in here
LDFLAGS="-L/home/yocto/milian/target-prefix/lib $LDFLAGS" \
prefix=/home/yocto/milian/target-prefix
> [root@jouet x-arm64]# cat /root/perf/android/r12b/arm/Dockerfile
> # docker.io/acmel/linux-perf-tools-build-android-ndk:r12b
> FROM docker.io/fedora:24
> MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
> ENV SOURCEFILE=android-ndk-r12b-linux-x86_64.zip
> RUN dnf -y install make bison flex unzip && \
> dnf -y clean all && \
> mkdir -m 777 -p /tmp/build/perf /tmp/build/objtool && \
> curl -OL http://dl.google.com/android/repository/${SOURCEFILE} && \
> unzip -d /opt ${SOURCEFILE} && \
> rm -f ${SOURCEFILE} && \
> rm -rf /opt/android-ndk-r12b/sources \
> /opt/android-ndk-r12b/platforms/android-[19]* \
> /opt/android-ndk-r12b/platforms/android-2[0-3]* \
> /opt/android-ndk-r12b/platforms/android-24/arch-mips* \
> /opt/android-ndk-r12b/platforms/android-24/arch-x86* \
> /opt/android-ndk-r12b/toolchains/x86* \
> /opt/android-ndk-r12b/toolchains/mips* \
> /opt/android-ndk-r12b/toolchains/llvm* \
> /opt/android-ndk-r12b/prebuilt/ \
> /opt/android-ndk-r12b/python* \
> /opt/android-ndk-r12b/shader-tools/ &&\
> groupadd -r perfbuilder && \
> useradd -r -g perfbuilder perfbuilder
> USER perfbuilder
> ENV NDK=/opt/android-ndk-r12b/
> ENV
> NDK_TOOLCHAIN=${NDK}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x8
> 6_64/bin/arm-linux-androideabi- ENV
> NDK_SYSROOT=${NDK}/platforms/android-24/arch-arm
> ENTRYPOINT make -C /git/linux/tools/perf O=/tmp/build/perf WERROR=0 ARCH=arm
> CROSS_COMPILE=${NDK_TOOLCHAIN} EXTRA_CFLAGS="-pie --sysroot=${NDK_SYSROOT}"
> && \ make -C /git/linux/tools/objtool O=/tmp/build/objtool WERROR=0
> ARCH=arm CROSS_COMPILE=${NDK_TOOLCHAIN} EXTRA_CFLAGS="-pie
> --sysroot=${NDK_SYSROOT}" [root@jouet x-arm64]#
>
> --------------------------------------------------------
>
> This one comes with a bit more pre-built devel packages, so did not have to
> cross build zlib (I'll copy the cross build of libelf to get a bit more code
> tested...) instead I threw away lots of toolchains for arches I didn't
> want, leaving just the ones for "arm-linux-androideabi-", running it we
> get:
>
> [root@jouet ~]# docker run -v /home/acme/git:/git:Z --rm -ti
> docker.io/acmel/linux-perf-tools-build-android-ndk:r12b make: Entering
> directory '/git/linux/tools/perf'
> BUILD: Doing 'make -j4' parallel build
>
> Auto-detecting system features:
> ... dwarf: [ OFF ]
> ... dwarf_getlocations: [ OFF ]
> ... glibc: [ OFF ]
glibc fails, but no fatal error is shown. from the make files I seem to
remember special casing for the bionic libc implementation, which doesn't seem
to be represented in the feature list.
<snip>
Still, good to see that the feature detection otherwise seems to work just
fine for your docker setups.
Thanks for the input, I'll get back to you once I know more about the failures
on my system. Btw.:
- would it be acceptable to add a warning/error to the build system when CC
contains more than the compiler name?
- would a patch be accepted to automatically add $prefix/include and $prefix/
lib to -I & -L via CFLAGS/LDFLAGS in the makefile (see above)?
If so, then I'd create some patches for that.
Cheers
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-08-04 21:58 ` Milian Wolff
@ 2016-08-05 0:13 ` Arnaldo Carvalho de Melo
2016-08-12 10:48 ` Milian Wolff
0 siblings, 1 reply; 15+ messages in thread
From: Arnaldo Carvalho de Melo @ 2016-08-05 0:13 UTC (permalink / raw)
To: Milian Wolff
Cc: hekuang, wangnan0, Jiri Olsa, Namhyung Kim, David Ahern,
Adrian Hunter, linux-perf-users
Em Thu, Aug 04, 2016 at 11:58:32PM +0200, Milian Wolff escreveu:
> On Donnerstag, 4. August 2016 15:36:05 CEST Arnaldo Carvalho de Melo wrote:
> > Em Thu, Aug 04, 2016 at 05:02:01PM +0200, Milian Wolff escreveu:
> > > On Thursday, August 4, 2016 10:22:25 AM CEST Arnaldo Carvalho de Melo
> wrote:
> > > > Em Wed, Aug 03, 2016 at 10:56:20PM +0200, Milian Wolff escreveu:
> > > > > I hope this helps others. I finally have a working up2date perf on my
> > > > > aarch64 platform and it seems to work form my simple 5min tests so
> > > > > far.
> > > >
> > > > Ok, that should help people, but it is way convoluted :-\
> > > >
> > > > How did you obtained your cross compiler environment? Some ready made
> > > > tarball or set of distro packages? I have an ever growing set of perf
> > >
> > > > build cointainers that includes a few cross compilers:
> > > The environment was provided to us as a tarball from a customer of ours,
> > > who probably got that from another subcontractor.
> > >
> > > <snip>
> > >
> > > export INSTALLDIR=/usr/${TARGET} && \
> > >
> > > ^-- is that path potentially special cased in the build file? I mean you
> > > don't
> > Huh? Not that I am aware, no, I just looked at where the existing cross
> > build packages were located, so that I used the same place for the cross
> > built versions of libelf and zlib:
>
<snip>
>
> > etc. So I assumed the best place to install the zlib and libelf devel files
> > was with that path prefix.
>
> Right, I think my point above was not clear: Since you essentially put your
> custom libelf into the implicit sysroot and also don't specify any prefix to
> install to, it seems to work out of the box. Is this the common way people
> build perf?
I have no idea besides what is documented for android in
tools/perf/Documentation/, and that uses a --sysroot
> From my experience working on e.g. KDE, one often has the sysroot
> (e.g. /usr), and then a bunch of custom stuff in a prefix somewhere in $HOME.
> Doing that with perf seems to be "hard", as it's not enough to do
> make prefix=$HOME/path/to/foo
>
> but instead one also needs to pass `-I.../include` and `-L.../lib` to
> EXTRA_CFLAGS & LDFLAGS. I'd be willing to supply a patch to simplify this
> process, if you think that is acceptable.
>
> > See it running:
>
> <snip>
>
> > See? The features it is finding are just the ones related to having glibc,
> > zlib and libelf devel packages that can be used in a cross build.
>
> OK, good to know. Then this clearly is something else special to my setup,
> similar to my initial problems with `--sysroot` being defined in `CC` rather
> than `EXTRA_CFLAGS`. I'll try to dig into that eventually.
>
> > > set the sysroot anywhere, nor do you seem to pass special include paths to
> > > perf. This of course works fine in a docker environment, but for "normal"
> > > development machines, where you compile and install stuff somewhere in
> > > $HOME, this won't work at all.
> >
> > Hey, a "docker environment" should be no different than a "normal"
> > development machine, it should work just the same, its just the former will
> > run inside a container, but the packages are the same I would install in my
> > workstation if I wanted to pollute it with a cross compiler environment.
> > Since I want to install tons of cross compiler environments, I better use
> > some sort of container, docker being the most popular, I picked it.
>
> My point here is exactly the pollution that happens in my non-containered
> environment. There, I have tons of dev packages installed in e.g. /usr, which
> may potentially get picked up, as well as the "actual" stuff that should be
> used from the sysroot. But, again, at this point this is just speculation.
Sure, this is a valid concern and one that should grand creating a few
more containers, taking advantage of its layers stuff to reduce the
space needed, i.e. share the base stuff I have and then have another set
with the native devel packages, to test that there is no pollution and
the results are the expected ones in a cross compile env.
> If you have the time, could you try to install some more x86 dev packages in
> your docker environments? E.g. when you install libunwind(-x86-64) - does it
I'll try what I described above, which is in line with your suggestion.
> then get picked up by your arm cross compile, or does it work as it should?
> That data point would help me figure out what could go wrong.
Will try tomorrow, if time allows, and will do it in the container
fashion, i.e. it should be a few more containers, testing this
possibility.
> > > The above wouldn't directly explain the really strange behavior of the
> > > feature detection though (which enables _everything_ for me).
> >
> > That is strage, yes, and I haven't even tried to figure out why this
> > happens in your case, I was just trying to show cross compiler
> > environments where the cross build of perf works, perhaps that would
> > help you figure out your specific case.
>
> Yep, it does help (see above). Thanks!
>
> > Further example, here is the Android NDK one, that is on top of Fedora 24
> > instead of the previous example, that is on top of Ubuntu 16.04, and here
> > you may have your answer, i.e. use EXTRA_CFLAGS to set --sysroot, I got
> > that from tools/perf/Documentation/android.txt:
>
> I do pass --sysroot to EXTRA_CFLAGS via CFLAGS. From my previous mail:
>
> export CFLAGS="--sysroot=...
> # ^-- CFLAGS contains --sysroot
>
> make ...\
> EXTRA_CFLAGS="$CFLAGS -I/home/yocto/milian/target-prefix/include" \
> # ^--- and gets passed in here
> LDFLAGS="-L/home/yocto/milian/target-prefix/lib $LDFLAGS" \
> prefix=/home/yocto/milian/target-prefix
>
> > [root@jouet x-arm64]# cat /root/perf/android/r12b/arm/Dockerfile
> > # docker.io/acmel/linux-perf-tools-build-android-ndk:r12b
> > FROM docker.io/fedora:24
> > MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
> > ENV SOURCEFILE=android-ndk-r12b-linux-x86_64.zip
> > RUN dnf -y install make bison flex unzip && \
> > dnf -y clean all && \
> > mkdir -m 777 -p /tmp/build/perf /tmp/build/objtool && \
> > curl -OL http://dl.google.com/android/repository/${SOURCEFILE} && \
> > unzip -d /opt ${SOURCEFILE} && \
> > rm -f ${SOURCEFILE} && \
> > rm -rf /opt/android-ndk-r12b/sources \
> > /opt/android-ndk-r12b/platforms/android-[19]* \
> > /opt/android-ndk-r12b/platforms/android-2[0-3]* \
> > /opt/android-ndk-r12b/platforms/android-24/arch-mips* \
> > /opt/android-ndk-r12b/platforms/android-24/arch-x86* \
> > /opt/android-ndk-r12b/toolchains/x86* \
> > /opt/android-ndk-r12b/toolchains/mips* \
> > /opt/android-ndk-r12b/toolchains/llvm* \
> > /opt/android-ndk-r12b/prebuilt/ \
> > /opt/android-ndk-r12b/python* \
> > /opt/android-ndk-r12b/shader-tools/ &&\
> > groupadd -r perfbuilder && \
> > useradd -r -g perfbuilder perfbuilder
> > USER perfbuilder
> > ENV NDK=/opt/android-ndk-r12b/
> > ENV
> > NDK_TOOLCHAIN=${NDK}/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x8
> > 6_64/bin/arm-linux-androideabi- ENV
> > NDK_SYSROOT=${NDK}/platforms/android-24/arch-arm
> > ENTRYPOINT make -C /git/linux/tools/perf O=/tmp/build/perf WERROR=0 ARCH=arm
> > CROSS_COMPILE=${NDK_TOOLCHAIN} EXTRA_CFLAGS="-pie --sysroot=${NDK_SYSROOT}"
> > && \ make -C /git/linux/tools/objtool O=/tmp/build/objtool WERROR=0
> > ARCH=arm CROSS_COMPILE=${NDK_TOOLCHAIN} EXTRA_CFLAGS="-pie
> > --sysroot=${NDK_SYSROOT}" [root@jouet x-arm64]#
> >
> > --------------------------------------------------------
> >
> > This one comes with a bit more pre-built devel packages, so did not have to
> > cross build zlib (I'll copy the cross build of libelf to get a bit more code
> > tested...) instead I threw away lots of toolchains for arches I didn't
> > want, leaving just the ones for "arm-linux-androideabi-", running it we
> > get:
> >
> > [root@jouet ~]# docker run -v /home/acme/git:/git:Z --rm -ti
> > docker.io/acmel/linux-perf-tools-build-android-ndk:r12b make: Entering
> > directory '/git/linux/tools/perf'
> > BUILD: Doing 'make -j4' parallel build
> >
> > Auto-detecting system features:
> > ... dwarf: [ OFF ]
> > ... dwarf_getlocations: [ OFF ]
> > ... glibc: [ OFF ]
>
> glibc fails, but no fatal error is shown. from the make files I seem to
> remember special casing for the bionic libc implementation, which doesn't seem
> to be represented in the feature list.
Right, in this case we _expect_ glibc to fail, IIRC, because it is not
present in this environment.
> <snip>
>
> Still, good to see that the feature detection otherwise seems to work just
> fine for your docker setups.
>
> Thanks for the input, I'll get back to you once I know more about the failures
> on my system. Btw.:
>
> - would it be acceptable to add a warning/error to the build system when CC
> contains more than the compiler name?
> - would a patch be accepted to automatically add $prefix/include and $prefix/
> lib to -I & -L via CFLAGS/LDFLAGS in the makefile (see above)?
>
> If so, then I'd create some patches for that.
Send patches for each of these cases, make sure to CC Jiri Olsa,
Namhyung Kim, Wang Nan, they all worked at the makefiles and hopefully
will chime in, some in cross environments, like Wang and He.
- Arnaldo
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: cross compiling perf
2016-08-05 0:13 ` Arnaldo Carvalho de Melo
@ 2016-08-12 10:48 ` Milian Wolff
0 siblings, 0 replies; 15+ messages in thread
From: Milian Wolff @ 2016-08-12 10:48 UTC (permalink / raw)
To: acme
Cc: hekuang, wangnan0, jolsa, namhyung, dsahern, adrian.hunter,
linux-perf-users
[-- Attachment #1: Type: text/plain, Size: 5656 bytes --]
On Thursday, August 4, 2016 9:13:27 PM CEST Arnaldo Carvalho de Melo wrote:
> Em Thu, Aug 04, 2016 at 11:58:32PM +0200, Milian Wolff escreveu:
> > On Donnerstag, 4. August 2016 15:36:05 CEST Arnaldo Carvalho de Melo
wrote:
> > > Em Thu, Aug 04, 2016 at 05:02:01PM +0200, Milian Wolff escreveu:
> > > > On Thursday, August 4, 2016 10:22:25 AM CEST Arnaldo Carvalho de Melo
> >
> > wrote:
> > > > > Em Wed, Aug 03, 2016 at 10:56:20PM +0200, Milian Wolff escreveu:
> > > > > > I hope this helps others. I finally have a working up2date perf on
> > > > > > my
> > > > > > aarch64 platform and it seems to work form my simple 5min tests so
> > > > > > far.
> > > > >
> > > > > Ok, that should help people, but it is way convoluted :-\
> > > > >
> > > > > How did you obtained your cross compiler environment? Some ready
> > > > > made
> > > > > tarball or set of distro packages? I have an ever growing set of
> > > > > perf
> > > >
> > > > > build cointainers that includes a few cross compilers:
> > > > The environment was provided to us as a tarball from a customer of
> > > > ours,
> > > > who probably got that from another subcontractor.
> > > >
> > > > <snip>
> > > >
> > > > export INSTALLDIR=/usr/${TARGET} && \
> > > >
> > > > ^-- is that path potentially special cased in the build file? I mean
> > > > you
> > > > don't
> > >
> > > Huh? Not that I am aware, no, I just looked at where the existing cross
> > > build packages were located, so that I used the same place for the cross
>
> > > built versions of libelf and zlib:
> <snip>
>
> > > etc. So I assumed the best place to install the zlib and libelf devel
> > > files
> > > was with that path prefix.
> >
> > Right, I think my point above was not clear: Since you essentially put
> > your
> > custom libelf into the implicit sysroot and also don't specify any prefix
> > to install to, it seems to work out of the box. Is this the common way
> > people build perf?
>
> I have no idea besides what is documented for android in
> tools/perf/Documentation/, and that uses a --sysroot
>
> > From my experience working on e.g. KDE, one often has the sysroot
> > (e.g. /usr), and then a bunch of custom stuff in a prefix somewhere in
> > $HOME. Doing that with perf seems to be "hard", as it's not enough to do
> >
> > make prefix=$HOME/path/to/foo
> >
> > but instead one also needs to pass `-I.../include` and `-L.../lib` to
> > EXTRA_CFLAGS & LDFLAGS. I'd be willing to supply a patch to simplify this
> > process, if you think that is acceptable.
> >
> > > See it running:
> > <snip>
> >
> > > See? The features it is finding are just the ones related to having
> > > glibc,
> > > zlib and libelf devel packages that can be used in a cross build.
> >
> > OK, good to know. Then this clearly is something else special to my setup,
> > similar to my initial problems with `--sysroot` being defined in `CC`
> > rather than `EXTRA_CFLAGS`. I'll try to dig into that eventually.
> >
> > > > set the sysroot anywhere, nor do you seem to pass special include
> > > > paths to
> > > > perf. This of course works fine in a docker environment, but for
> > > > "normal"
> > > > development machines, where you compile and install stuff somewhere in
> > > > $HOME, this won't work at all.
> > >
> > > Hey, a "docker environment" should be no different than a "normal"
> > > development machine, it should work just the same, its just the former
> > > will
> > > run inside a container, but the packages are the same I would install in
> > > my
> > > workstation if I wanted to pollute it with a cross compiler environment.
> > > Since I want to install tons of cross compiler environments, I better
> > > use
> > > some sort of container, docker being the most popular, I picked it.
> >
> > My point here is exactly the pollution that happens in my non-containered
> > environment. There, I have tons of dev packages installed in e.g. /usr,
> > which may potentially get picked up, as well as the "actual" stuff that
> > should be used from the sysroot. But, again, at this point this is just
> > speculation.
> Sure, this is a valid concern and one that should grand creating a few
> more containers, taking advantage of its layers stuff to reduce the
> space needed, i.e. share the base stuff I have and then have another set
> with the native devel packages, to test that there is no pollution and
> the results are the expected ones in a cross compile env.
>
> > If you have the time, could you try to install some more x86 dev packages
> > in your docker environments? E.g. when you install libunwind(-x86-64) -
> > does it
> I'll try what I described above, which is in line with your suggestion.
>
> > then get picked up by your arm cross compile, or does it work as it
> > should?
> > That data point would help me figure out what could go wrong.
>
> Will try tomorrow, if time allows, and will do it in the container
> fashion, i.e. it should be a few more containers, testing this
> possibility.
Update: It seems to me that the above mess-up was due to some left-over build
artifact. I just tried to reproduce this with an up2date git checkout after
doing a hearty `git clean -xfd` in my linux tree. The issue is gone. I thought
to have done that before, but apparently that is not the case...
Sorry for the noise. I hope it may help someone out there who might run into
that issue again in the future. I'll remember to use `git clean -xfd` before I
report any other build related issues.
Cheers
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-08-12 10:49 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-06-15 14:24 cross compiling perf Milian Wolff
2016-06-15 15:47 ` Kim Phillips
2016-06-27 11:56 ` Milian Wolff
2016-06-16 16:11 ` Arnaldo Carvalho de Melo
2016-06-17 9:49 ` Milian Wolff
2016-06-17 11:00 ` Arnaldo Carvalho de Melo
2016-06-20 1:56 ` Wangnan (F)
2016-06-27 11:56 ` Milian Wolff
2016-08-03 20:56 ` Milian Wolff
2016-08-04 13:22 ` Arnaldo Carvalho de Melo
2016-08-04 15:02 ` Milian Wolff
2016-08-04 18:36 ` Arnaldo Carvalho de Melo
2016-08-04 21:58 ` Milian Wolff
2016-08-05 0:13 ` Arnaldo Carvalho de Melo
2016-08-12 10:48 ` Milian Wolff
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).