cross compiling perf

linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* 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 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-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-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).