summaryrefslogtreecommitdiffstats
path: root/meta/recipes-kernel/perf/perf.bb
AgeCommit message (Collapse)Author
2020-04-06perf: Fix externalsrc supportPaul Barker
When the externalsrc class is used the tasks listed in SRCTREECOVEREDTASKS are deleted to prevent them being executed. If externalsrc is used for the kernel then this will include virtual/kernel:do_patch. We can depend on do_shared_workdir instead as this will survive when externalsrc is used. Signed-off-by: Paul Barker <pbarker@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit eab605bab94552046ec4adae5debe026cc03bb4c) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
2019-09-16perf: fix build on kernels which don't have ${S}/tools/include/linux/bits.hMartin Jansa
* tools/include/linux/bits.h was added in v4.20-rc1 with this commit: commit ba4aa02b417f08a0bee5e7b8ed70cac788a7c854 Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Tue Sep 25 10:55:59 2018 -0300 tools include: Adopt linux/bits.h * also if you're building for such older kernel you will probably see do_compile failing with: | config/Makefile:448: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev | config/Makefile:495: Python 3 is not yet supported; please set | config/Makefile:496: PYTHON and/or PYTHON_CONFIG appropriately. easiest work around is to disable scripting PACKAGECONFIG, because since oe-core commit: commit 584af667e0000129bcb5c9e8108485f2f6590eaf Author: Bruce Ashfield <bruce.ashfield@gmail.com> Date: Wed Aug 28 22:14:41 2019 -0400 perf: change dependencies on python to python3 The upstream kernel can now handle python3 for the perf scripts, coupled with the impending EOL of python2, we switch the dependencies in perf (scripting) to python3. it now uses python3, but the support for that was added in kernel v4.17-rc1 with: commit 66dfdff03d196e51322c6a85c0d8db8bb2bdd655 Author: Jaroslav Skarvada <jskarvad@redhat.com> Date: Fri Jan 19 21:56:41 2018 +0100 perf tools: Add Python 3 support Added Python 3 support while keeping Python 2.7 compatibility. if you really need scripting support than either backport the kernel patch to your kernel or undo the perf recipe changes. Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2019-08-30perf: v5.3+ build fixesBruce Ashfield
In the 5.3+ perf builds, there are multiple unistd.h files that need to be kept in sync. So not only do we update one, we update both to ensure that libc-headers and the perf build are in sync. perf checks some key files itself to be sure they are in sync, and bits.h can be out of sync. There's no build error that results with bits.h at the moment, but we still make sure they are in sync to avoid the configure/compile warning. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-08-30perf: change dependencies on python to python3Bruce Ashfield
The upstream kernel can now handle python3 for the perf scripts, coupled with the impending EOL of python2, we switch the dependencies in perf (scripting) to python3. Outside of dependency changes, we also pass the following two variables to the perf build: PYTHON=python3 PYTHON_CONFIG=python3-config. To ensure that our python3 components are used. For configurations that disable perf scripting, there is no change in behaviour. [YOCTO #13358] Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-05-15perf: make sure that the tools/include/uapi/asm-generic directory existsMartin Jansa
* before trying to copy unistd.h into it * older kernels don't have uapi in tools/include and do_configure fails with: DEBUG: Executing shell function do_configure cp: cannot create regular file '.../perf/1.0-r9/perf-1.0/tools/include/uapi/asm-generic/unistd.h': No such file or directory WARNING: exit code 1 from a shell command. * tools/include/uapi was added in kernel 4.8 with https://github.com/torvalds/linux/commit/c4b6014e8bb0c8d47fe5c71ebc604f31091e5d3f tools: Add copy of perf_event.h to tools/include/linux/ Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-04-11perf: workaround the error cased by maybe-uninitialized warningDengke Du
When enable DEBUG_BUILD, the perf build failed by the following error: libbpf.c:727:36: error: 'data' may be used uninitialized in this function [-Werror=maybe-uninitialized] This is ok until Khem commit a patch in oe-core: 16643b03227466e2c80a24c2d079fe36e89553c1 This commit import "-Og" option to "DEBUG_OPTIMIZATION", result in this error. Actually, the warning was misinformation. We explore the code in libbpf.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/bpf/libbpf.c#n640 -------------------------------------------------------------------------- if (scn) data = elf_getdata(scn, NULL); if (!scn || !data) { pr_warning("failed to get Elf_Data from map section %d\n", obj->efile.maps_shndx); return -EINVAL; } ...... using data... ...... -------------------------------------------------------------------------- If the 'scn' was not null, the data will be initialized. if the data was null, the function will return -EINVAL, so the data must be not null, but compiler can't see it in 'if' code block, so treat it as 'maybe-uninitialized'. Signed-off-by: Dengke Du <dengke.du@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-03-09perf: synchronize unistd.h between libc-headers and perf sourceBruce Ashfield
During the build for some architectures, perf generates a program which executes on the host to dump the syscall table. The generation of that program uses the cross compiler + sysroot to expand unistd.h. As such, we are getting the contents of that file from linux-libc-headers. The compilation of that generated program uses the host compiler and a restricted include path to the perf source code. In the perf source there is a captured unistd.h, as such it will be used when compiling the host executable. The perf source code is copied from the kernel version that is being built .. so we have a mismatch between the generation and the compilation of the host program. Normally this mismatch is fine, but if the libc-headers are newer than the kernel, we'll have syscalls (and their syscall numbers) that are not defined in the perf source code. This leads to a compiler error and a cascading failure of the perf build due to a missing generated file. To fix this, we can copy unistd.h from the recipe-sysroot into the perf source code and they will always be in sync. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-03-01perf: Set libunwind dir explicitly to point into staging sysrootKhem Raj
This helps it find the unwind library in sysroot always and not look around and confuse with host Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-02-16perf: Package libperf-jvmti.so as part of ${PN}Alex Kiernan
perf's jvmti support builds libperf-jvmti.so that needs to be packaged as part of the main package, not a developer package. Given there's no files in the developer package, override FILES_SOLIBSDEV so it's not gobbled by FILES_${PN}-dev, and then add just that file to FILES_${PN} so that if in the future there other files which would be added to the dev package we'll fail then. Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-11-06perf: Disable libunwind for ARC & RISCV64Alexey Brodkin
libunwind is not yet ported for ARC & RISCV64 and on attempt to build it for those arches we just get an error message. If we explicitly disable libunwind it is gracefully handled by perf build system and it just gets configured to not use it so perf is still usable even on those arches. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-10-20perf: fix do_compile failure with /tmp mounted with noexecHongxu Jia
On a builder which has /tmp mounted nexec, the ARM64 generation of the sycall table will fail: [snip] |perf-1.0/tools/perf/arch/arm64/entry/syscalls//mksyscalltbl: /tmp/create-table-6VGPSt: Permission denied [snip] To avoid the permission denied error, we must instruct the perf build to place temporary files in an appropriate directory (versus always using /tmp). To do this, we need both a kernel source change to perf, and a recipe change to pass the temp directory in by a TMPDIR variable. The linux-yocto has a reference kernel change: [perf arm64: Fix generate system call table failed with /tmp mounted with noexec], that has also been submitted upstream mailing list linux-perf-users@vger.kernel.org Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Reviewed-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-10-10perf: make tools needed for API documentation respect the manpages PACKAGECONFIGRoss Burton
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-09-13perf: do not pull in any perl dependencies unless scripting is requestedDima Zavin
Signed-off-by: Dima Zavin <dmitriyz@waymo.com> Signed-off-by: Andrew Bresticker <abrestic@waymo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-08-14perf: fail if src path does not existMikko Rapeli
A missing src directory from a broken kernel recipe resulted only in a warning: WARNING: copyfile: stat of /home/builder/src/tmp-glibc/work-shared/target/kernel-source/tools/arch failed ([Errno 2] No such file or directory: '/home/builder/src/tmp-glibc/work-shared/target/kernel-source/tools/arch') and the build failed horribly. With this change it's an error which can not be missed: ERROR: perf-1.0-r9 do_configure: Path does not exist: /home/builder/src/tmp-glibc/work-shared/target/kernel-source/tools/arch. Maybe PERF_SRC does not match the kernel version. ERROR: perf-1.0-r9 do_configure: Function failed: copy_perf_source_from_kernel ERROR: Logfile of failure stored in: /home/builder/src/tmp-glibc/work/target-linux/perf/1.0-r9/temp/log.do_configure.21083 NOTE: recipe perf-1.0-r9: task do_configure: Failed ERROR: Task (/home/builder/src/poky/meta/recipes-kernel/perf/perf.bb:do_configure) failed with exit code '1' To get get perf compiling from a custom kernel, a perf.bbappend can be created which defines PERF_SRC as list of files and directories needed from kernel source tree to compile perf. This varies between kernel versions. Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-08-14perf: inherit manpages instead of adding man to RDEPENDS_${PN}-docMartin Jansa
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-07-13perf: add dwarf to PACKAGECONFIGAnuj Mittal
Enable perf to be built with DWARF support. Fixes [YOCTO #3359] Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2018-07-13perf: disable parallelism for 'make clean'Rasmus Villemoes
Whenever perf got rebuilt, I was consistently getting errors such as | find: '[...]/perf/1.0-r9/perf-1.0/plugin_mac80211.so': No such file or directory | find: '[...]/perf/1.0-r9/perf-1.0/plugin_mac80211.so': No such file or directory | find: find: '[...]/perf/1.0-r9/perf-1.0/libtraceevent.a''[...]/perf/1.0-r9/perf-1.0/libtraceevent.a': No such file or directory: No such file or directory | [...] | find: cannot delete '/mnt/xfs/devel/pil/yocto/tmp-glibc/work/wandboard-oe-linux-gnueabi/perf/1.0-r9/perf-1.0/util/.pstack.o.cmd': No such file or directory breaking the whole build. The root cause seems to be that the implicit 'make clean' done during do_configure ends up running in parallel, and thus multiple find commands attempt to stat and/or delete the same file. A patch disabling parallelism for the clean target has been ack'ed upstream (lkml.kernel.org/r/20180705134955.GB3686@krava), but it should be harmless to pass JOBS=1 even with a fixed kernel. This can be removed if and when all relevant -stable kernels have that patch. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by: Ross Burton <ross.burton@intel.com>
2018-05-29perf: fix build with kernel older than 4.8Martin Jansa
* perf is failing to build for me since this oe-core commit: commit 9b38c824961fc9dce51bda95c25dac91a69fc64f Author: Hongxu Jia <hongxu.jia@windriver.com> Date: Tue Apr 24 11:33:47 2018 +0800 perf: make a copy of kernel source to perf workdir the problem is that perf sources in kernel older than 4.8 (in my case 4.4) are depending on the "global" include headers outside tools directory, e.g. swab.h in: kernel-source/tools$ git grep swab.h perf/MANIFEST:include/linux/swab.h perf/MANIFEST:include/uapi/linux/swab.h perf/util/include/asm/byteorder.h:#include "../../../../include/uapi/linux/swab.h" this was resolved in 4.8 with: commit 7e3f36411342a54f1981fa97b43550b8406a3d69 Author: Arnaldo Carvalho de Melo <acme@redhat.com> Date: Mon Jul 18 17:42:16 2016 -0300 perf tools: Remove tools/perf/util/include/asm/byteorder.h Not used anymore. This also stops include linux/swab.h directly from the kernel sources, remove that reference from the MANIFEST. and few more changes to make tools/include more complete and standalone: tools/include in 4.15: asm asm-generic linux tools trace uapi tools/include in 4.4: asm asm-generic linux tools but copying the include header even for kernels which don't really need it doesn't add big overhead, so just copy include to perf sources for all kernels. Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2018-05-04perf: make a copy of kernel source to perf workdirHongxu Jia
Since perf contaminates linux shared workdir, it probably caused kernel-devsrc compile failure at world build. ... |0 blocks |cpio: ./tools/perf/arch/arm/util/sedr7ORqk: Cannot stat: No such file or directory |0 blocks ... cpio tried to find a file at ${S}/tools/perf and failed if the input list is not valid. Make a copy of kernel shared source directory into a perf workdir could fix the issue. Drop `Fix for rebuilding' which is obsolete [YOCTO #10880] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2018-03-20perf: enable support for libauditAnuj Mittal
perf needs audit-python to be able to show syscall names and for 'perf trace' to work. Enable dependency on audit-python if present in PACKAGECONFIG. It's disabled by default since audit as of now is in meta-selinux. Fixes [YOCTO #3343] Fixes [YOCTO #3358] Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2018-03-04perf: fix packaging of scripting modulesAnuj Mittal
Make sure that python and perl scripts are packaged in the correct rpm. Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2018-01-14perf: conditionalise pythonnative and perlnative inheritsRoss Burton
Only inherit these classes (and so, add perl-native and python-native to DEPENDS) if the scripting PACKAGECONFIG is actually enabled. Signed-off-by: Ross Burton <ross.burton@intel.com>
2018-01-11perf: depend on native versions of bison and flexDenys Dmytriyenko
Explicitly depend on bison-native and flex-native for deterministic builds, as those are required for the build: | Makefile.config:129: *** Error: flex is missing on this system, please install it. Stop. | Makefile.perf:205: recipe for target 'sub-make' failed | make[1]: *** [sub-make] Error 2 | Makefile:68: recipe for target 'all' failed | make: *** [all] Error 2 | Makefile.config:133: *** Error: bison is missing on this system, please install it. Stop. | Makefile.perf:205: recipe for target 'sub-make' failed | make[1]: *** [sub-make] Error 2 | Makefile:68: recipe for target 'all' failed | make: *** [all] Error 2 In most cases, those dependencies come indirectly via toolchain dependencies, specifically binutils-cross, which pulls both bison-native and flex-native. Different setups, such as with external toolchain, would expose this problem, since correct dependency is not marked explicitly. The change is build-tested on all qemu architectures. Signed-off-by: Denys Dmytriyenko <denys@ti.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-05perf: Add HOMEPAGE info into recipe file.Fan Xin
Signed-off-by: Fan Xin <fan.xin@jp.fujitsu.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-06-16meta: Drop further remnants of uclibc supportRichard Purdie
uclibc support was removed a while ago and musl works much better. Start to remove the various overrides and patches related to uclibc which are no longer needed. uclibc support in a layer would still be possible. I have strong reasons to believe nobody is still using uclibc since patches are missing and I doubt the metadata even parses anymore. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-06-09perf: enable libunwindRoss Burton
Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-02-15perf: add PACKAGECONFIG for jvmtiStefan Müller-Klieser
Recent kernel build jvmti, java profiling agent, if a host jdk is detected. The library will be packaged in -dev and throws a qa error. Disable the jvmti build per default. Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-01-19perf: add PACKAGECONFIG for systemtapRoss Burton
Otherwise it's possible to race with systemtap headers being present during the autodetection and disappearing during the build: tests/sdt.c:14:21: fatal error: sys/sdt.h: No such file or directory #include <sys/sdt.h> ^ Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-01-19perf: use PACKAGECONFIG instead of hand-rolled logicRoss Burton
PERF_FEATURES_ENABLE and perf_feature_enabled() was basically a poor man's clone of PACKAGECONFIG, without the automatic handling of dependencies and configure options. As part of the port to PACKAGECONFIG the options have been changed to remove the perf- prefix, but are otherwise unchanged. Also remove BUILDPERF_libc_uclibc assignment as nothing in the metadata uses a BUILDPERF variable. Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-12-16meta: remove True option to getVar callsJoshua Lock
getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-11-30perf: Add EXTRA_LDFLAGS for MIPS N32Zubair Lutfullah Kakakhel
MIPS N32 requires EXTRA_LDFLAGS to link correctly. Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-10-28Remove LIC_FILES_CHKSUM from recipes without SRC_URIOlaf Mandel
LICENSE and LIC_FILES_CHKSUM apply to the sources specified by SRC_URI, not to the recipe itself. As such a license declaration for a source-less recipe makes little sense. The LICENSE declaration is mandatory, but LIC_FILES_CHKSUM can be removed in such cases. Remove the LIC_FILES_CHKSUM declarations from all recipes that do not need it. CC: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-10-05perf: Fix to obey LD failureSujith Haridasan
This patch brings the last bit from meta-mentor for the perf to build successfully with minnowmax BSP. The meta-mentor commit for the same is: http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/meta-mentor-staging?id=a8db95c0d4081cf96915e0c3c4063a44f55e21cc The previous fix: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-kernel/perf?id=ef942d6025e1a339642b10ec1e29055f4ee6bd46 was incomplete and was not submitted upstream. And due to that this change is required. When built on minnowmax ( machine name: intel-corei7-64), an error is noticed during the do_compile: /home/sujith/codebench-linux-install-2015.12-133-i686-pc-linux-gnu/codebench/bin/i686-pc-linux-gnu-ld: Relocatable linking with relocations from format elf64-x86-64 (/home/sujith/MEL/dogwood/build-minnowmax/tmp/work/intel_corei7_64-mel-linux/perf/1.0-r9/perf-1.0/fd/array.o) to format elf32-i386 (/home/sujith/MEL/dogwood/build-minnowmax/tmp/work/intel_corei7_64-mel-linux/perf/1.0-r9/perf-1.0/fd/libapi-in.o) is not supported This change help fix the issue. Signed-off-by: Sujith Haridasan <Sujith_Haridasan@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-09-22perf: Fix to obey LD failure on qemux86-64Christopher Larson
When built on an i686 host for qemux86-64 without the fix to obey LD and it fails: /scratch/dogwood/toolchains/x86_64/bin/i686-pc-linux-gnu-ld: Relocatable linking with relocations from format elf64-x86-64 (/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_64-mel-linux/perf/1.0-r9/perf-1.0/fs/fs.o) to format elf32-i386 (/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_64-mel-linux/perf/1.0-r9/perf-1.0/fs/libapi-in.o) is not supported This is because LD includes HOST_LD_ARCH, which contains TUNE_LDARGS, which is -m elf32_x86_64 for x86_64. Without that, direct use of ld will fail. Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Sujith Haridasan <Sujith_Haridasan@mentor.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-09-05perf: adapt to Makefile.configBruce Ashfield
commit 4842576cd857 [perf tools: Move config/Makefile into Makefile.config] relocated the configuration Makefile of perf. As such, we need to adapt our fixup routines to work with the Makefile no matter where it is. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-08-17Use PYTHON_SITEPACKAGES_DIR insted of hard-coded *site-packages*Ming Liu
For thoese recipes that are inheriting python*-dir.bbclass, there is already a PYTHON_SITEPACKAGES_DIR present, use that definition replacing redundant "${libdir}/python*/site-packages". Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-08-04perf: enable man pages for 'help' functionalityDengke Du
When using 'perf help <subcommand>', it can't find 'man' command and pages for perf. The perf man pages depends on the xmlto-native and asciidoc-native, so we just need to add the two packages to the DEPENDS variable and add 'man'to RDEPENDS_perf-doc. Signed-off-by: Dengke Du <dengke.du@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-01pythonnative.bbclass, python3native.bbclass: export STAGING_INCDIR, ↵Alexander Kanavin
STAGING_LIBDIR, PYTHON variables We patch Python's distutils modules to access STAGING_INCDIR/LIBDIR, so when they are not set, scripts that utilize distutils (e.g. python-config) fail. Several recipes need to export those manually to prevent such failures, so let's do that in the class instead. PYTHON variable is exported because otherwise autotools' python.m4 macro will pick up its own internal default, which may not be the version that we want. glib recipe in particular was previously using Python 2.x during build due to python.m4 defaulting to it - now it's using Python 3.x, and so needs a small fix in deletion of *.pyc files. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-05-30python-native, python3-native: remove the use of exported HOST_SYS and ↵Alexander Kanavin
BUILD_SYS variables The code that utilized them was superseded by the code (in the same patch!) that is utilizing STAGING_LIBDIR/STAGING_INCDIR, and wasn't correct in the first place as HOST_SYS is not necessarily the same as the sysroot directory name. Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
2016-04-19perf: pass DESTDIR in EXTRA_OEMAKERoss Burton
Instead of passing DESTDIR just in the make install invocation, pass it in EXTRA_OEMAKE. This appears to stop perf from rebuilding at instal time for me, which appears to be the trigger for the random build failure. [ YOCTO #9182 ] Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-24perf: package python modules into perf-pythonBruce Ashfield
The scripts that are part of perf require python and supporting modules. The existing perf-pyton dependency only brought in core python, which left us unable to actually execute the scripts on target. With this additional runtime dependency, we can now execte the sample analysis scripts when perf-scripting is availble. This is a partial fix for [YOCTO #9069], since there are still scripts looking for non-existent modules, and those will be dealt with in future releases. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-03-24perf: fix python scripts QA errorsBruce Ashfield
Two QA warnings were being generated from perf, due to the location of python scripts changing in the kernel build: WARNING: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf-core/scripts/python/call-graph-from-postgresql.py contained in package perf-python requires /usr/bin/python2, but no providers found in RDEPENDS_perf-python? [file-rdeps] WARNING: QA Issue: /usr/libexec/perf-core/tests/attr.py_perf contained in package perf requires /usr/bin/python, but no providers found in its RDEPENDS [file-rdeps] By adding libexec dir to both the tests and scripts packaging, we get the appropriate RDEPENDS on the packages that actually contain the python scripts (without making perf-core depend on python). We also tweak any python scripts to use '/usr/bin/env python', rather than a version specific python, since it won't be provided and generate a QA error. [YOCTO #8991] Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-26perf: add sysroot handling to subcmdMartin Donnelly
v4.5-rc1 of the kernel splits the subcommand related files from perf into a new library, this patch adds the modification of the Makefile to preserve the --sysroot option as for the other perf related Makefiles. Signed-off-by: Martin Donnelly <martin.donnelly@ge.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-16meta: more removals of redunant FILES_${PN}-dbgRoss Burton
In some recipes overly-split -dbg packages were merged into PN-dbg. Unless there's a very good reason, recipes should have a single -dev and -dbg package. Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-09-16perf: mkdir ${B} -> mkdir -p ${B}Robert Yang
${B} is the default cwd of tasks, so there might be race issues such as: | mkdir: cannot create directory `/path/to/work/qemux86-poky-linux/perf/1.0-r9/perf-1.0/': File exists [snip] NOTE: recipe perf-1.0-r9: task do_configure: Failed Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-09-16perf: fix the install-python_ext on upstream kernelRoy Li
The Perf source code between Yocto and upstream are different, like below commit is not in upstream, so broaden the "--root" replacement to Makefile* commit 33e96fb1e2d77541e81eb341ccd3fbe9419e4c9a Author: Tom Zanussi <tom.zanussi@intel.com> Date: Tue Jul 3 13:07:23 2012 -0500 perf: change --root to --prefix for python install Otherwise we get the sysroot path appended to the build path, not what we want. Signed-off-by: Tom Zanussi <tom.zanussi@intel.com> Signed-off-by: Roy Li <rongqing.li@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-09-12perf: fix the install-python_extRoy Li
1. $(grep xxx xxx) never returns 0, it maybe return empty or string, and can not compare with 0, this fixes that python module never are installed. 2. python library is installed into /usr/lib/ by default, but we expect it is installed into ${libdir}, so add --install-lib parameter for python setup.py to set the library dir; this fixes not shipped warning, since python modules are installed into /usr/lib/, but FILE_${PN}-python expects it is under ${libdir}, which is /usr/lib64/ for 64bit machine 3. the makefile target install-python_ext is moved from Makefile to Makefile.perf from linux v3.13, so match install-python_ext in Makefile.* and --root='/\$(DESTDIR_SQ)' before linux v3.13 will install the target python library to native sysroot, so replace it with --prefix as after linux 3.13; this fixes not shipped warning, and install target files to native dir, like below: ERROR: QA Issue: perf: Files/directories were installed but not shipped in any package: /home /home/pokybuild /home/pokybuild/yocto-autobuilder /home/pokybuild/yocto-autobuilder/yocto-worker /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7 /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/perf.so /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/perf-0.1-py2.7.egg-info Signed-off-by: Roy Li <rongqing.li@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-08-12perf: fix build breakage on kernels after 4.1Reinette Chatre
A recent commit fixed perf build failures with a change that duplicates a fix that can be found in kernels after 4.1. Unfortunately there is a conflict between these two fixes and we see perf build failures when building perf in kernels that contain the fix already. The problem is that the fix from the recipe modifies the location of .config-detected to $(OUTPUT).config-detected. In a 4.2 kernel the location will be changed to $(OUTPUT)$(OUTPUT).config-detected. We change the recipe to require a space in the pattern to only change kernel sources that do not already place file in $(OUTPUT). The recent commit that introduced the build failure is: commit ea9016b60b47138bc58d84a06954b44527b20a19 Author: Richard Purdie <richard.purdie@linuxfoundation.org> Date: Sat Jul 25 14:37:58 2015 +0100 perf: Fix config file conflict with 4.1 kernels If you setup mutlitlibs and then: bitbake perf libb32-perf bitbake perf libb32-perf -c cleansstate bitbake perf libb32-perf you will see races where the two builds get confused about which directory they should be using and they corrupt each other. The issue is that .config-detected is created in ${S}, not $(OUTPUT). We can fix this by moving the file to $(OUTPUT). [YCOTO #8043] (From OE-Core rev: 00608cffffb586e8d2a2075117e710113c471448) (From OE-Core rev: 57df1ebd910e42af47a0039830a60f41a3bd29b6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> The commit in the kernel source that fixes the problem from kernel side is: commit 642273795fa81da11290ffa90bce6ff242f2a7bb Author: Aaro Koskinen <aaro.koskinen@nokia.com> Date: Wed Jul 1 14:54:42 2015 +0300 perf tools: Create config.detected into OUTPUT directory Create config.detected into OUTPUT directory instead of source directory. This fixes parallel builds that share the same source directory. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1435751683-18500-1-git-send-email-aaro.koskinen@nokia.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-07-31perf: add liblzma depdenencyBruce Ashfield
With kernel commit 6c6f0f6164f [tools build: Add feature check for lzma library], perf now performs a test for lzma and adds functionality appropriately. This currently is a floating dependency that will sometimes be present, and sometimes not. The result is the following QA warning: WARNING: QA Issue: perf rdepends on liblzma, but it isn't a build dependency? [build-deps] By adding xz to the DEPENDS, we'll ensure that it is consistently in place. [YOCTO: #8045] Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-07-25perf: Fix config file conflict with 4.1 kernelsRichard Purdie
If you setup mutlitlibs and then: bitbake perf libb32-perf bitbake perf libb32-perf -c cleansstate bitbake perf libb32-perf you will see races where the two builds get confused about which directory they should be using and they corrupt each other. The issue is that .config-detected is created in ${S}, not $(OUTPUT). We can fix this by moving the file to $(OUTPUT). [YCOTO #8043] Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pan>=uImage QEMUZYNQ_DEFAULT_FSTYPE=cpio AKITA_DEFAULT_KERNEL=zImage-akita.bin AKITA_DEFAULT_FSTYPE=jffs2 SPITZ_DEFAULT_KERNEL=zImage-spitz.bin SPITZ_DEFAULT_FSTYPE=ext3 setup_path_vars() { if [ -z "$OE_TMPDIR" ] ; then PATHS_REQUIRED=true elif [ "$1" = "1" -a -z "$DEPLOY_DIR_IMAGE" ] ; then PATHS_REQUIRED=true else PATHS_REQUIRED=false fi if [ "$PATHS_REQUIRED" = "true" ]; then # Try to get the variable values from bitbake type -P bitbake &>/dev/null || { echo "In order for this script to dynamically infer paths"; echo "to kernels or filesystem images, you either need"; echo "bitbake in your PATH or to source oe-init-build-env"; echo "before running this script" >&2; exit 1; } # We have bitbake in PATH, get the variable values from bitbake BITBAKE_ENV_TMPFILE=`mktemp --tmpdir runqemu.XXXXXXXXXX` if [ "$?" != "0" ] ; then echo "Error: mktemp failed for bitbake environment output" exit 1 fi MACHINE=$MACHINE bitbake -e > $BITBAKE_ENV_TMPFILE if [ -z "$OE_TMPDIR" ] ; then OE_TMPDIR=`sed -n 's/^TMPDIR=\"\(.*\)\"/\1/p' $BITBAKE_ENV_TMPFILE` fi if [ -z "$DEPLOY_DIR_IMAGE" ] ; then DEPLOY_DIR_IMAGE=`sed -n 's/^DEPLOY_DIR_IMAGE=\"\(.*\)\"/\1/p' $BITBAKE_ENV_TMPFILE` fi if [ -z "$OE_TMPDIR" ]; then # Check for errors from bitbake that the user needs to know about BITBAKE_OUTPUT=`cat $BITBAKE_ENV_TMPFILE | wc -l` if [ "$BITBAKE_OUTPUT" -eq "0" ]; then echo "Error: this script needs to be run from your build directory, or you need" echo "to explicitly set OE_TMPDIR and DEPLOY_DIR_IMAGE in your environment" else echo "There was an error running bitbake to determine TMPDIR" echo "Here is the output from 'bitbake -e':" cat $BITBAKE_ENV_TMPFILE fi rm $BITBAKE_ENV_TMPFILE exit 1 fi rm $BITBAKE_ENV_TMPFILE fi } setup_sysroot() { # Toolchain installs set up $OECORE_NATIVE_SYSROOT in their # environment script. If that variable isn't set, we're # either in an in-tree build scenario or the environment # script wasn't source'd. if [ -z "$OECORE_NATIVE_SYSROOT" ]; then setup_path_vars BUILD_ARCH=`uname -m` BUILD_OS=`uname | tr '[A-Z]' '[a-z]'` BUILD_SYS="$BUILD_ARCH-$BUILD_OS" OECORE_NATIVE_SYSROOT=$OE_TMPDIR/sysroots/$BUILD_SYS fi # Some recipes store the BIOS under $OE_TMPDIR/sysroots/$MACHINE, # now defined as OECORE_MACHINE_SYSROOT. The latter is used when searching # BIOS, VGA BIOS and keymaps. if [ -z "$OECORE_MACHINE_SYSROOT" ]; then OECORE_MACHINE_SYSROOT=$OE_TMPDIR/sysroots/$MACHINE fi } # Locate a rootfs image to boot which matches our expected # machine and fstype. findimage() { where=$1 machine=$2 extension=$3 # Sort rootfs candidates by modification time - the most # recently created one is the one we most likely want to boot. filename=`ls -t1 $where/*-image*$machine.$extension 2>/dev/null | head -n1` if [ "x$filename" != "x" ]; then ROOTFS=$filename return fi echo "Couldn't find a $machine rootfs image in $where." exit 1 } if [ -e "$ROOTFS" -a -z "$FSTYPE" ]; then # Extract the filename extension EXT=`echo $ROOTFS | awk -F . '{ print \$NF }'` if [ "x$EXT" = "xext2" -o "x$EXT" = "xext3" -o \ "x$EXT" = "xjffs2" -o "x$EXT" = "xbtrfs" -o \ "x$EXT" = "xext4" ]; then FSTYPE=$EXT else echo "Note: Unable to determine filesystem extension for $ROOTFS" echo "We will use the default FSTYPE for $MACHINE" # ...which is done further below... fi fi if [ -z "$KERNEL" -a "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then setup_path_vars 1 eval kernel_file=\$${machine2}_DEFAULT_KERNEL KERNEL=$DEPLOY_DIR_IMAGE/$kernel_file if [ -z "$KERNEL" ]; then error "Unable to determine default kernel for MACHINE [$MACHINE]" fi fi # KERNEL is now set for all cases if [ -z "$FSTYPE" ]; then eval FSTYPE=\$${machine2}_DEFAULT_FSTYPE if [ -z "$FSTYPE" ]; then error "Unable to determine default fstype for MACHINE [$MACHINE]" fi fi # FSTYPE is now set for all cases # Handle cases where a ROOTFS type is given instead of a filename, e.g. # core-image-sato if [ "$LAZY_ROOTFS" = "true" ]; then setup_path_vars 1 echo "Assuming $ROOTFS really means $DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE" if [ "$FSTYPE" = "hddimg" -o "x$FSTYPE" = "xhdddirect" ]; then VM=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE else ROOTFS=$DEPLOY_DIR_IMAGE/$ROOTFS-$MACHINE.$FSTYPE fi fi if [ -z "$ROOTFS" -a "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then setup_path_vars 1 T=$DEPLOY_DIR_IMAGE eval rootfs_list=\$${machine2}_DEFAULT_ROOTFS findimage $T $MACHINE $FSTYPE if [ -z "$ROOTFS" ]; then error "Unable to determine default rootfs for MACHINE [$MACHINE]" fi fi # ROOTFS is now set for all cases, now expand it to be an absolute path, it should exist at this point ROOTFS=`readlink -f $ROOTFS` echo "" echo "Continuing with the following parameters:" if [ "x$FSTYPE" != "xvmdk" -a "x$FSTYPE" != "xhddimg" -a "x$FSTYPE" != "xhdddirect" ]; then echo "KERNEL: [$KERNEL]" echo "ROOTFS: [$ROOTFS]" else echo "VMDK: [$VM]" fi echo "FSTYPE: [$FSTYPE]" setup_sysroot # OECORE_NATIVE_SYSROOT and OECORE_MACHINE_SYSROOT are now set for all cases INTERNAL_SCRIPT="$0-internal" if [ ! -f "$INTERNAL_SCRIPT" -o ! -r "$INTERNAL_SCRIPT" ]; then INTERNAL_SCRIPT=`which runqemu-internal` fi # Specify directory for BIOS, VGA BIOS and keymaps if [ ! -z "$CUSTOMBIOSDIR" ]; then if [ -d "$OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR" ]; then echo "Assuming biosdir is $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR" SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR" elif [ -d "$OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR" ]; then echo "Assuming biosdir is $OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR" SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L $OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR" else if [ ! -d "$CUSTOMBIOSDIR" ]; then echo "Custom BIOS directory not found. Tried: $CUSTOMBIOSDIR" echo "and $OECORE_NATIVE_SYSROOT/$CUSTOMBIOSDIR" echo "and $OECORE_MACHINE_SYSROOT/$CUSTOMBIOSDIR" exit 1; fi echo "Assuming biosdir is $CUSTOMBIOSDIR" SCRIPT_QEMU_OPT="$SCRIPT_QEMU_OPT -L $CUSTOMBIOSDIR" fi fi . $INTERNAL_SCRIPT exit $?