2013-06-06 01:53:30 +02:00
|
|
|
################################################################################
|
2013-01-06 06:22:45 +01:00
|
|
|
#
|
|
|
|
|
# perf
|
|
|
|
|
#
|
2013-06-06 01:53:30 +02:00
|
|
|
################################################################################
|
2013-01-06 06:22:45 +01:00
|
|
|
|
2015-07-14 19:35:14 +02:00
|
|
|
LINUX_TOOLS += perf
|
2013-01-06 06:22:45 +01:00
|
|
|
|
2015-07-14 19:35:14 +02:00
|
|
|
PERF_DEPENDENCIES = host-flex host-bison
|
2013-01-06 06:22:45 +01:00
|
|
|
|
2015-07-14 19:35:11 +02:00
|
|
|
ifeq ($(KERNEL_ARCH),x86_64)
|
|
|
|
|
PERF_ARCH=x86
|
|
|
|
|
else
|
|
|
|
|
PERF_ARCH=$(KERNEL_ARCH)
|
|
|
|
|
endif
|
|
|
|
|
|
2013-01-06 06:22:45 +01:00
|
|
|
PERF_MAKE_FLAGS = \
|
|
|
|
|
$(LINUX_MAKE_FLAGS) \
|
2016-03-11 19:19:55 +01:00
|
|
|
JOBS=$(PARALLEL_JOBS) \
|
2015-07-14 19:35:11 +02:00
|
|
|
ARCH=$(PERF_ARCH) \
|
2016-03-11 19:19:56 +01:00
|
|
|
DESTDIR=$(TARGET_DIR) \
|
|
|
|
|
prefix=/usr \
|
|
|
|
|
WERROR=0 \
|
2013-01-06 06:22:45 +01:00
|
|
|
NO_LIBAUDIT=1 \
|
|
|
|
|
NO_GTK2=1 \
|
|
|
|
|
NO_LIBPERL=1 \
|
|
|
|
|
NO_LIBPYTHON=1 \
|
2016-03-11 19:19:56 +01:00
|
|
|
NO_LIBBIONIC=1
|
2013-01-06 06:22:45 +01:00
|
|
|
|
2017-02-17 11:59:05 +01:00
|
|
|
# We need to pass an argument to ld for setting the emulation when
|
|
|
|
|
# building for MIPS architecture, otherwise the default one will always
|
|
|
|
|
# be used and the compilation for most variants will fail.
|
|
|
|
|
ifeq ($(BR2_mips),y)
|
|
|
|
|
PERF_MAKE_FLAGS += LD="$(TARGET_LD) -m elf32btsmip"
|
|
|
|
|
else ifeq ($(BR2_mipsel),y)
|
|
|
|
|
PERF_MAKE_FLAGS += LD="$(TARGET_LD) -m elf32ltsmip"
|
|
|
|
|
else ifeq ($(BR2_mips64),y)
|
|
|
|
|
ifeq ($(BR2_MIPS_NABI32),y)
|
|
|
|
|
PERF_MAKE_FLAGS += LD="$(TARGET_LD) -m elf32btsmipn32"
|
|
|
|
|
else
|
|
|
|
|
PERF_MAKE_FLAGS += LD="$(TARGET_LD) -m elf64btsmip"
|
|
|
|
|
endif
|
|
|
|
|
else ifeq ($(BR2_mips64el),y)
|
|
|
|
|
ifeq ($(BR2_MIPS_NABI32),y)
|
|
|
|
|
PERF_MAKE_FLAGS += LD="$(TARGET_LD) -m elf32ltsmipn32"
|
|
|
|
|
else
|
|
|
|
|
PERF_MAKE_FLAGS += LD="$(TARGET_LD) -m elf64ltsmip"
|
|
|
|
|
endif
|
2016-02-22 11:22:45 +01:00
|
|
|
endif
|
|
|
|
|
|
2014-01-28 14:10:58 +01:00
|
|
|
# The call to backtrace() function fails for ARC, because for some
|
|
|
|
|
# reason the unwinder from libgcc returns early. Thus the usage of
|
|
|
|
|
# backtrace() should be disabled in perf explicitly: at build time
|
|
|
|
|
# backtrace() appears to be available, but it fails at runtime: the
|
|
|
|
|
# backtrace will contain only several functions from the top of stack,
|
|
|
|
|
# instead of the complete backtrace.
|
|
|
|
|
ifeq ($(BR2_arc),y)
|
2015-03-31 09:21:57 +02:00
|
|
|
PERF_MAKE_FLAGS += NO_BACKTRACE=1
|
2014-01-28 14:10:58 +01:00
|
|
|
endif
|
|
|
|
|
|
2018-04-02 16:02:49 +02:00
|
|
|
ifeq ($(BR2_PACKAGE_LINUX_TOOLS_PERF_TUI),y)
|
2015-07-14 19:35:08 +02:00
|
|
|
PERF_DEPENDENCIES += slang
|
2016-03-11 19:19:56 +01:00
|
|
|
else
|
2018-04-02 16:02:49 +02:00
|
|
|
PERF_MAKE_FLAGS += NO_NEWT=1 NO_SLANG=1
|
2015-07-14 19:35:08 +02:00
|
|
|
endif
|
|
|
|
|
|
2015-07-14 19:35:10 +02:00
|
|
|
ifeq ($(BR2_PACKAGE_LIBUNWIND),y)
|
|
|
|
|
PERF_DEPENDENCIES += libunwind
|
2016-03-11 19:19:56 +01:00
|
|
|
else
|
|
|
|
|
PERF_MAKE_FLAGS += NO_LIBUNWIND=1
|
2015-07-14 19:35:10 +02:00
|
|
|
endif
|
|
|
|
|
|
2015-07-14 19:35:09 +02:00
|
|
|
ifeq ($(BR2_PACKAGE_NUMACTL),y)
|
|
|
|
|
PERF_DEPENDENCIES += numactl
|
2016-03-11 19:19:56 +01:00
|
|
|
else
|
|
|
|
|
PERF_MAKE_FLAGS += NO_LIBNUMA=1
|
2015-07-14 19:35:09 +02:00
|
|
|
endif
|
|
|
|
|
|
2013-01-06 06:22:46 +01:00
|
|
|
ifeq ($(BR2_PACKAGE_ELFUTILS),y)
|
2015-03-31 09:21:57 +02:00
|
|
|
PERF_DEPENDENCIES += elfutils
|
2013-01-06 06:22:46 +01:00
|
|
|
else
|
2015-03-31 09:21:57 +02:00
|
|
|
PERF_MAKE_FLAGS += NO_LIBELF=1 NO_DWARF=1
|
2013-01-06 06:22:46 +01:00
|
|
|
endif
|
|
|
|
|
|
2016-03-11 19:19:57 +01:00
|
|
|
ifeq ($(BR2_PACKAGE_ZLIB),y)
|
|
|
|
|
PERF_DEPENDENCIES += zlib
|
|
|
|
|
else
|
|
|
|
|
PERF_MAKE_FLAGS += NO_ZLIB=1
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# lzma is provided by xz
|
|
|
|
|
ifeq ($(BR2_PACKAGE_XZ),y)
|
|
|
|
|
PERF_DEPENDENCIES += xz
|
|
|
|
|
else
|
|
|
|
|
PERF_MAKE_FLAGS += NO_LZMA=1
|
|
|
|
|
endif
|
|
|
|
|
|
linux/perf: really do not build the documentation
The perf buildsystem, inside the kernel, is not really amenable to be
easily used...
Regarding the documentation, it will forcefully try to detect asciidoc
and, with the latest versions, xmlto, completely disregarding what the
user may provide.
We currently pass ASCIIDOC= (the empty string) on the make command line,
as an attempt to disable building the documentation, but that has no
effect whatsoever on perf: that variable is not passed down to the
sub-sub-make (yes, a two-level depth) that is responsible for building
the documentation.
We really do not want to build any of the documentation (the user can
refer to the documentation on his own development machine), so we use a
little dirty trick: we provide a GNUmakefile beside the existing
Makefile for the documentation; GNUmakefile always takes precedence over
a Makefile when both are present. We only provide a catch-all-no-recipe
rule in that GNUmakefile, so it really does nothing useful, except avoid
building the documentation.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-11 19:19:54 +01:00
|
|
|
# We really do not want to build the perf documentation, because it
|
|
|
|
|
# has stringent requirement on the documentation generation tools,
|
|
|
|
|
# like xmlto and asciidoc), which may be lagging behind on some
|
|
|
|
|
# distributions.
|
|
|
|
|
# We name it 'GNUmakefile' so that GNU make will use it instead of
|
|
|
|
|
# the existing 'Makefile'.
|
|
|
|
|
define PERF_DISABLE_DOCUMENTATION
|
linux/tools: make it a real, separate package
The kernel source tree also contains the sources for various userland
tools, of which cpupower, perf or selftests.
Currently, we have support for building those tools as part of the
kernel build procedure. This looked the correct thing to do so far,
because, well, they *are* part of the kernel source tree and some
really have to be the same version as the kernel that will run.
However, this is causing quite a non-trivial-to-break circular
dependency in some configurations. For example, this defconfig fails to
build (similar to the one reported by Paul):
BR2_arm=y
BR2_cortex_a7=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_SYSTEMD=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y
BR2_PACKAGE_CRYPTODEV=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_LIBCURL=y
This causes a circular dependency, as explained by Thomas:
- When libcurl is enabled, systemd depends on it
- When OpenSSL is enabled, obviously, will use it for SSL support
- When cryptodev-linux is enabled, OpenSSL will depend on it to use
crypto accelerators supported in the kernel via cryptodev-linux.
- cryptodev-linux being a kernel module, it depends on linux
- linux by itself (the kernel) does not depend on pciutils, but the
linux tool "cpupower" (managed in linux-tool-cpupower) depends on
pciutils
- pciutils depends on udev when available
- udev is provided by systemd.
And indeed, during the build, we can see that make warns (it's only
reported as a *warning*, not as an actual error):
[...]
make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured
<- cryptodev-linux dependency dropped.
>>> openssl 1.0.2h Downloading
[...]
So the build fails later on, when openssl is actually built:
eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory
compilation terminated.
<builtin>: recipe for target 'eng_cryptodev.o' failed
Furthermore, graph-depends also detects the circular dependency, but
treats it as a hard-error:
Recursion detected for : cryptodev-linux
which is a dependency of: openssl
which is a dependency of: libcurl
which is a dependency of: systemd
which is a dependency of: udev
which is a dependency of: pciutils
which is a dependency of: linux
which is a dependency of: cryptodev-linux
Makefile:738: recipe for target 'graph-depends' failed
Of course, there is no way to break the loop without losing
functionality in either one of the involved packages *and* keep
our infrastructure and packages as-is.
The only solution is to break the loop at the linux-tools level, by
moving them away into their own package, so that the linux package will
no longer have the opportunity to depend on another package via a
dependency of one the tools.
All three linux tools are thus moved away to their own package.
The package infrastructure only knows of three types of packages: those
in package/ , in boot/ , in toolchain/ and the one in linux/ . So we
create that new linux-tools package in package/ so that we don't have to
fiddle with yet another special case in the infra. Still, we want its
configure options to appear in the kernel's sub-menu.
So, we make it a prompt-less package, with only the tools visible as
options of that package, but without the usual dependency on their
master symbol; they only depend on the Linux kernel.
Furthermore, because the kernel is such a huge pile of code, we would
not be very happy to extract it a second time just for the sake of a few
tools. We can't extract only the tools/ sub-directory from the kernel
source either, because some tools have hard-coded path to includes from
the kernel (arch and stuff).
Instead, we just use the linux source tree as our own build tree, and
ensure the linux tree is extracted and patched before linux-tools is
configured and built.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
if [ -f $(LINUX_DIR)/tools/perf/Documentation/Makefile ]; then \
|
|
|
|
|
printf "%%:\n\t@:\n" >$(LINUX_DIR)/tools/perf/Documentation/GNUmakefile; \
|
linux/perf: really do not build the documentation
The perf buildsystem, inside the kernel, is not really amenable to be
easily used...
Regarding the documentation, it will forcefully try to detect asciidoc
and, with the latest versions, xmlto, completely disregarding what the
user may provide.
We currently pass ASCIIDOC= (the empty string) on the make command line,
as an attempt to disable building the documentation, but that has no
effect whatsoever on perf: that variable is not passed down to the
sub-sub-make (yes, a two-level depth) that is responsible for building
the documentation.
We really do not want to build any of the documentation (the user can
refer to the documentation on his own development machine), so we use a
little dirty trick: we provide a GNUmakefile beside the existing
Makefile for the documentation; GNUmakefile always takes precedence over
a Makefile when both are present. We only provide a catch-all-no-recipe
rule in that GNUmakefile, so it really does nothing useful, except avoid
building the documentation.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-11 19:19:54 +01:00
|
|
|
fi
|
|
|
|
|
endef
|
|
|
|
|
LINUX_POST_PATCH_HOOKS += PERF_DISABLE_DOCUMENTATION
|
|
|
|
|
|
2015-07-14 19:35:14 +02:00
|
|
|
# O must be redefined here to overwrite the one used by Buildroot for
|
linux/tools: make it a real, separate package
The kernel source tree also contains the sources for various userland
tools, of which cpupower, perf or selftests.
Currently, we have support for building those tools as part of the
kernel build procedure. This looked the correct thing to do so far,
because, well, they *are* part of the kernel source tree and some
really have to be the same version as the kernel that will run.
However, this is causing quite a non-trivial-to-break circular
dependency in some configurations. For example, this defconfig fails to
build (similar to the one reported by Paul):
BR2_arm=y
BR2_cortex_a7=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_SYSTEMD=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y
BR2_PACKAGE_CRYPTODEV=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_LIBCURL=y
This causes a circular dependency, as explained by Thomas:
- When libcurl is enabled, systemd depends on it
- When OpenSSL is enabled, obviously, will use it for SSL support
- When cryptodev-linux is enabled, OpenSSL will depend on it to use
crypto accelerators supported in the kernel via cryptodev-linux.
- cryptodev-linux being a kernel module, it depends on linux
- linux by itself (the kernel) does not depend on pciutils, but the
linux tool "cpupower" (managed in linux-tool-cpupower) depends on
pciutils
- pciutils depends on udev when available
- udev is provided by systemd.
And indeed, during the build, we can see that make warns (it's only
reported as a *warning*, not as an actual error):
[...]
make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured
<- cryptodev-linux dependency dropped.
>>> openssl 1.0.2h Downloading
[...]
So the build fails later on, when openssl is actually built:
eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory
compilation terminated.
<builtin>: recipe for target 'eng_cryptodev.o' failed
Furthermore, graph-depends also detects the circular dependency, but
treats it as a hard-error:
Recursion detected for : cryptodev-linux
which is a dependency of: openssl
which is a dependency of: libcurl
which is a dependency of: systemd
which is a dependency of: udev
which is a dependency of: pciutils
which is a dependency of: linux
which is a dependency of: cryptodev-linux
Makefile:738: recipe for target 'graph-depends' failed
Of course, there is no way to break the loop without losing
functionality in either one of the involved packages *and* keep
our infrastructure and packages as-is.
The only solution is to break the loop at the linux-tools level, by
moving them away into their own package, so that the linux package will
no longer have the opportunity to depend on another package via a
dependency of one the tools.
All three linux tools are thus moved away to their own package.
The package infrastructure only knows of three types of packages: those
in package/ , in boot/ , in toolchain/ and the one in linux/ . So we
create that new linux-tools package in package/ so that we don't have to
fiddle with yet another special case in the infra. Still, we want its
configure options to appear in the kernel's sub-menu.
So, we make it a prompt-less package, with only the tools visible as
options of that package, but without the usual dependency on their
master symbol; they only depend on the Linux kernel.
Furthermore, because the kernel is such a huge pile of code, we would
not be very happy to extract it a second time just for the sake of a few
tools. We can't extract only the tools/ sub-directory from the kernel
source either, because some tools have hard-coded path to includes from
the kernel (arch and stuff).
Instead, we just use the linux source tree as our own build tree, and
ensure the linux tree is extracted and patched before linux-tools is
configured and built.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
# out of tree build. We build perf in $(LINUX_DIR)/tools/perf/ and not just
|
|
|
|
|
# $(LINUX_DIR) so that it isn't built in the root directory of the kernel
|
2015-07-14 19:35:14 +02:00
|
|
|
# sources.
|
2013-01-06 06:22:45 +01:00
|
|
|
define PERF_BUILD_CMDS
|
linux/tools: make it a real, separate package
The kernel source tree also contains the sources for various userland
tools, of which cpupower, perf or selftests.
Currently, we have support for building those tools as part of the
kernel build procedure. This looked the correct thing to do so far,
because, well, they *are* part of the kernel source tree and some
really have to be the same version as the kernel that will run.
However, this is causing quite a non-trivial-to-break circular
dependency in some configurations. For example, this defconfig fails to
build (similar to the one reported by Paul):
BR2_arm=y
BR2_cortex_a7=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_SYSTEMD=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y
BR2_PACKAGE_CRYPTODEV=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_LIBCURL=y
This causes a circular dependency, as explained by Thomas:
- When libcurl is enabled, systemd depends on it
- When OpenSSL is enabled, obviously, will use it for SSL support
- When cryptodev-linux is enabled, OpenSSL will depend on it to use
crypto accelerators supported in the kernel via cryptodev-linux.
- cryptodev-linux being a kernel module, it depends on linux
- linux by itself (the kernel) does not depend on pciutils, but the
linux tool "cpupower" (managed in linux-tool-cpupower) depends on
pciutils
- pciutils depends on udev when available
- udev is provided by systemd.
And indeed, during the build, we can see that make warns (it's only
reported as a *warning*, not as an actual error):
[...]
make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured
<- cryptodev-linux dependency dropped.
>>> openssl 1.0.2h Downloading
[...]
So the build fails later on, when openssl is actually built:
eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory
compilation terminated.
<builtin>: recipe for target 'eng_cryptodev.o' failed
Furthermore, graph-depends also detects the circular dependency, but
treats it as a hard-error:
Recursion detected for : cryptodev-linux
which is a dependency of: openssl
which is a dependency of: libcurl
which is a dependency of: systemd
which is a dependency of: udev
which is a dependency of: pciutils
which is a dependency of: linux
which is a dependency of: cryptodev-linux
Makefile:738: recipe for target 'graph-depends' failed
Of course, there is no way to break the loop without losing
functionality in either one of the involved packages *and* keep
our infrastructure and packages as-is.
The only solution is to break the loop at the linux-tools level, by
moving them away into their own package, so that the linux package will
no longer have the opportunity to depend on another package via a
dependency of one the tools.
All three linux tools are thus moved away to their own package.
The package infrastructure only knows of three types of packages: those
in package/ , in boot/ , in toolchain/ and the one in linux/ . So we
create that new linux-tools package in package/ so that we don't have to
fiddle with yet another special case in the infra. Still, we want its
configure options to appear in the kernel's sub-menu.
So, we make it a prompt-less package, with only the tools visible as
options of that package, but without the usual dependency on their
master symbol; they only depend on the Linux kernel.
Furthermore, because the kernel is such a huge pile of code, we would
not be very happy to extract it a second time just for the sake of a few
tools. We can't extract only the tools/ sub-directory from the kernel
source either, because some tools have hard-coded path to includes from
the kernel (arch and stuff).
Instead, we just use the linux source tree as our own build tree, and
ensure the linux tree is extracted and patched before linux-tools is
configured and built.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
$(Q)if test ! -f $(LINUX_DIR)/tools/perf/Makefile ; then \
|
2013-01-06 06:22:47 +01:00
|
|
|
echo "Your kernel version is too old and does not have the perf tool." ; \
|
|
|
|
|
echo "At least kernel 2.6.31 must be used." ; \
|
|
|
|
|
exit 1 ; \
|
|
|
|
|
fi
|
|
|
|
|
$(Q)if test "$(BR2_PACKAGE_ELFUTILS)" = "" ; then \
|
linux/tools: make it a real, separate package
The kernel source tree also contains the sources for various userland
tools, of which cpupower, perf or selftests.
Currently, we have support for building those tools as part of the
kernel build procedure. This looked the correct thing to do so far,
because, well, they *are* part of the kernel source tree and some
really have to be the same version as the kernel that will run.
However, this is causing quite a non-trivial-to-break circular
dependency in some configurations. For example, this defconfig fails to
build (similar to the one reported by Paul):
BR2_arm=y
BR2_cortex_a7=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_SYSTEMD=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y
BR2_PACKAGE_CRYPTODEV=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_LIBCURL=y
This causes a circular dependency, as explained by Thomas:
- When libcurl is enabled, systemd depends on it
- When OpenSSL is enabled, obviously, will use it for SSL support
- When cryptodev-linux is enabled, OpenSSL will depend on it to use
crypto accelerators supported in the kernel via cryptodev-linux.
- cryptodev-linux being a kernel module, it depends on linux
- linux by itself (the kernel) does not depend on pciutils, but the
linux tool "cpupower" (managed in linux-tool-cpupower) depends on
pciutils
- pciutils depends on udev when available
- udev is provided by systemd.
And indeed, during the build, we can see that make warns (it's only
reported as a *warning*, not as an actual error):
[...]
make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured
<- cryptodev-linux dependency dropped.
>>> openssl 1.0.2h Downloading
[...]
So the build fails later on, when openssl is actually built:
eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory
compilation terminated.
<builtin>: recipe for target 'eng_cryptodev.o' failed
Furthermore, graph-depends also detects the circular dependency, but
treats it as a hard-error:
Recursion detected for : cryptodev-linux
which is a dependency of: openssl
which is a dependency of: libcurl
which is a dependency of: systemd
which is a dependency of: udev
which is a dependency of: pciutils
which is a dependency of: linux
which is a dependency of: cryptodev-linux
Makefile:738: recipe for target 'graph-depends' failed
Of course, there is no way to break the loop without losing
functionality in either one of the involved packages *and* keep
our infrastructure and packages as-is.
The only solution is to break the loop at the linux-tools level, by
moving them away into their own package, so that the linux package will
no longer have the opportunity to depend on another package via a
dependency of one the tools.
All three linux tools are thus moved away to their own package.
The package infrastructure only knows of three types of packages: those
in package/ , in boot/ , in toolchain/ and the one in linux/ . So we
create that new linux-tools package in package/ so that we don't have to
fiddle with yet another special case in the infra. Still, we want its
configure options to appear in the kernel's sub-menu.
So, we make it a prompt-less package, with only the tools visible as
options of that package, but without the usual dependency on their
master symbol; they only depend on the Linux kernel.
Furthermore, because the kernel is such a huge pile of code, we would
not be very happy to extract it a second time just for the sake of a few
tools. We can't extract only the tools/ sub-directory from the kernel
source either, because some tools have hard-coded path to includes from
the kernel (arch and stuff).
Instead, we just use the linux source tree as our own build tree, and
ensure the linux tree is extracted and patched before linux-tools is
configured and built.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
if ! grep -q NO_LIBELF $(LINUX_DIR)/tools/perf/Makefile* ; then \
|
|
|
|
|
if ! test -r $(LINUX_DIR)/tools/perf/config/Makefile ; then \
|
2014-04-05 14:51:02 +02:00
|
|
|
echo "The perf tool in your kernel cannot be built without libelf." ; \
|
|
|
|
|
echo "Either upgrade your kernel to >= 3.7, or enable the elfutils package." ; \
|
|
|
|
|
exit 1 ; \
|
|
|
|
|
fi \
|
2013-01-06 06:22:47 +01:00
|
|
|
fi \
|
|
|
|
|
fi
|
2018-04-02 16:02:49 +02:00
|
|
|
$(Q)if test "$(BR2_PACKAGE_LINUX_TOOLS_PERF_TUI)" = "y" ; then \
|
|
|
|
|
if ! grep -q NO_SLANG $(LINUX_DIR)/tools/perf/Makefile* ; then \
|
|
|
|
|
echo "The perf tool in your kernel cannot be build with the TUI." ; \
|
|
|
|
|
echo "Either upgrade your kernel to >= 3.10, or disable the TUI." ; \
|
|
|
|
|
exit 1 ; \
|
|
|
|
|
fi \
|
|
|
|
|
fi
|
2015-07-14 19:35:14 +02:00
|
|
|
$(TARGET_MAKE_ENV) $(MAKE1) $(PERF_MAKE_FLAGS) \
|
linux/tools: make it a real, separate package
The kernel source tree also contains the sources for various userland
tools, of which cpupower, perf or selftests.
Currently, we have support for building those tools as part of the
kernel build procedure. This looked the correct thing to do so far,
because, well, they *are* part of the kernel source tree and some
really have to be the same version as the kernel that will run.
However, this is causing quite a non-trivial-to-break circular
dependency in some configurations. For example, this defconfig fails to
build (similar to the one reported by Paul):
BR2_arm=y
BR2_cortex_a7=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_SYSTEMD=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y
BR2_PACKAGE_CRYPTODEV=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_LIBCURL=y
This causes a circular dependency, as explained by Thomas:
- When libcurl is enabled, systemd depends on it
- When OpenSSL is enabled, obviously, will use it for SSL support
- When cryptodev-linux is enabled, OpenSSL will depend on it to use
crypto accelerators supported in the kernel via cryptodev-linux.
- cryptodev-linux being a kernel module, it depends on linux
- linux by itself (the kernel) does not depend on pciutils, but the
linux tool "cpupower" (managed in linux-tool-cpupower) depends on
pciutils
- pciutils depends on udev when available
- udev is provided by systemd.
And indeed, during the build, we can see that make warns (it's only
reported as a *warning*, not as an actual error):
[...]
make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured
<- cryptodev-linux dependency dropped.
>>> openssl 1.0.2h Downloading
[...]
So the build fails later on, when openssl is actually built:
eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory
compilation terminated.
<builtin>: recipe for target 'eng_cryptodev.o' failed
Furthermore, graph-depends also detects the circular dependency, but
treats it as a hard-error:
Recursion detected for : cryptodev-linux
which is a dependency of: openssl
which is a dependency of: libcurl
which is a dependency of: systemd
which is a dependency of: udev
which is a dependency of: pciutils
which is a dependency of: linux
which is a dependency of: cryptodev-linux
Makefile:738: recipe for target 'graph-depends' failed
Of course, there is no way to break the loop without losing
functionality in either one of the involved packages *and* keep
our infrastructure and packages as-is.
The only solution is to break the loop at the linux-tools level, by
moving them away into their own package, so that the linux package will
no longer have the opportunity to depend on another package via a
dependency of one the tools.
All three linux tools are thus moved away to their own package.
The package infrastructure only knows of three types of packages: those
in package/ , in boot/ , in toolchain/ and the one in linux/ . So we
create that new linux-tools package in package/ so that we don't have to
fiddle with yet another special case in the infra. Still, we want its
configure options to appear in the kernel's sub-menu.
So, we make it a prompt-less package, with only the tools visible as
options of that package, but without the usual dependency on their
master symbol; they only depend on the Linux kernel.
Furthermore, because the kernel is such a huge pile of code, we would
not be very happy to extract it a second time just for the sake of a few
tools. We can't extract only the tools/ sub-directory from the kernel
source either, because some tools have hard-coded path to includes from
the kernel (arch and stuff).
Instead, we just use the linux source tree as our own build tree, and
ensure the linux tree is extracted and patched before linux-tools is
configured and built.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
-C $(LINUX_DIR)/tools/perf O=$(LINUX_DIR)/tools/perf/
|
2013-01-06 06:22:45 +01:00
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
# After installation, we remove the Perl and Python scripts from the
|
|
|
|
|
# target.
|
|
|
|
|
define PERF_INSTALL_TARGET_CMDS
|
2015-07-14 19:35:14 +02:00
|
|
|
$(TARGET_MAKE_ENV) $(MAKE1) $(PERF_MAKE_FLAGS) \
|
linux/tools: make it a real, separate package
The kernel source tree also contains the sources for various userland
tools, of which cpupower, perf or selftests.
Currently, we have support for building those tools as part of the
kernel build procedure. This looked the correct thing to do so far,
because, well, they *are* part of the kernel source tree and some
really have to be the same version as the kernel that will run.
However, this is causing quite a non-trivial-to-break circular
dependency in some configurations. For example, this defconfig fails to
build (similar to the one reported by Paul):
BR2_arm=y
BR2_cortex_a7=y
BR2_ARM_FPU_NEON_VFPV4=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_INIT_SYSTEMD=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/raspberrypi/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="26f3b72a9c049be10e6af196252283e1f6ab9d1f"
BR2_LINUX_KERNEL_DEFCONFIG="bcm2709"
BR2_PACKAGE_LINUX_TOOLS_CPUPOWER=y
BR2_PACKAGE_CRYPTODEV=y
BR2_PACKAGE_OPENSSL=y
BR2_PACKAGE_LIBCURL=y
This causes a circular dependency, as explained by Thomas:
- When libcurl is enabled, systemd depends on it
- When OpenSSL is enabled, obviously, will use it for SSL support
- When cryptodev-linux is enabled, OpenSSL will depend on it to use
crypto accelerators supported in the kernel via cryptodev-linux.
- cryptodev-linux being a kernel module, it depends on linux
- linux by itself (the kernel) does not depend on pciutils, but the
linux tool "cpupower" (managed in linux-tool-cpupower) depends on
pciutils
- pciutils depends on udev when available
- udev is provided by systemd.
And indeed, during the build, we can see that make warns (it's only
reported as a *warning*, not as an actual error):
[...]
make[1]: Circular /home/ymorin/dev/buildroot/O/build/openssl-1.0.2h/.stamp_configured
<- cryptodev-linux dependency dropped.
>>> openssl 1.0.2h Downloading
[...]
So the build fails later on, when openssl is actually built:
eng_cryptodev.c:57:31: fatal error: crypto/cryptodev.h: No such file or directory
compilation terminated.
<builtin>: recipe for target 'eng_cryptodev.o' failed
Furthermore, graph-depends also detects the circular dependency, but
treats it as a hard-error:
Recursion detected for : cryptodev-linux
which is a dependency of: openssl
which is a dependency of: libcurl
which is a dependency of: systemd
which is a dependency of: udev
which is a dependency of: pciutils
which is a dependency of: linux
which is a dependency of: cryptodev-linux
Makefile:738: recipe for target 'graph-depends' failed
Of course, there is no way to break the loop without losing
functionality in either one of the involved packages *and* keep
our infrastructure and packages as-is.
The only solution is to break the loop at the linux-tools level, by
moving them away into their own package, so that the linux package will
no longer have the opportunity to depend on another package via a
dependency of one the tools.
All three linux tools are thus moved away to their own package.
The package infrastructure only knows of three types of packages: those
in package/ , in boot/ , in toolchain/ and the one in linux/ . So we
create that new linux-tools package in package/ so that we don't have to
fiddle with yet another special case in the infra. Still, we want its
configure options to appear in the kernel's sub-menu.
So, we make it a prompt-less package, with only the tools visible as
options of that package, but without the usual dependency on their
master symbol; they only depend on the Linux kernel.
Furthermore, because the kernel is such a huge pile of code, we would
not be very happy to extract it a second time just for the sake of a few
tools. We can't extract only the tools/ sub-directory from the kernel
source either, because some tools have hard-coded path to includes from
the kernel (arch and stuff).
Instead, we just use the linux source tree as our own build tree, and
ensure the linux tree is extracted and patched before linux-tools is
configured and built.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Paul Ashford <paul.ashford@zurria.co.uk>
[Thomas:
- fix typo #(@D) -> $(@D)
- fix the inclusion of the per-tool .mk files.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-06 16:29:14 +02:00
|
|
|
-C $(LINUX_DIR)/tools/perf O=$(LINUX_DIR)/tools/perf/ install
|
2013-01-06 06:22:45 +01:00
|
|
|
$(RM) -rf $(TARGET_DIR)/usr/libexec/perf-core/scripts/
|
2016-01-15 09:47:35 +01:00
|
|
|
$(RM) -rf $(TARGET_DIR)/usr/libexec/perf-core/tests/
|
2013-01-06 06:22:45 +01:00
|
|
|
endef
|
