NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
a542d0fd55
kumquat-buildroot/package/oprofile/Config.in

38 lines
1.4 KiB
Plaintext
Raw Normal View History

add oprofile
2008-04-24 18:54:29 +02:00
config BR2_PACKAGE_OPROFILE
bool "oprofile"
oprofile: needs mmu Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-10-09 23:30:42 +02:00
depends on BR2_USE_MMU # fork()
add oprofile
2008-04-24 18:54:29 +02:00
select BR2_PACKAGE_POPT
oprofile: use new libbfd option Convert the oprofile target to select the new libbfd staging/target option to avoid a huge target binutils for a simple task. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-31 12:39:04 +01:00
select BR2_PACKAGE_BINUTILS
oprofile 0.9.8: fix compilation on powerpc The oprofile build was broken on powerpc since version 0.9.8. This was detected in several autobuilds, like http://autobuild.buildroot.net/results/6f6c02d18495907d50fcdfc6003ac20d493c55fe/ Thomas Petazzoni had some fixes pending in his own tree, and this patch is partially based on this work (credits to him). Here is an overview: - I took over (and fixed) the oprofile.mk changes, except for the powerpc- specific part. For powerpc, there is a new dependency to libpfm4. - I reimported those Yocto patches that were specific to the ppc build issues, but left out the other ones. Those can be added in separate commits. [Peter: simplify libpfm4 check] Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2013-03-21 10:03:17 +01:00
select BR2_PACKAGE_LIBPFM4 if BR2_powerpc
package/: depend on toolchain C++ config, don't use select select should only be used for package (library) dependencies.
2009-01-26 20:19:10 +01:00
depends on BR2_INSTALL_LIBSTDCPP
binutils: enable as target package for aarch64 binutils got disabled as a target package for aarch64 back in Buildroot 2012.11 (commit 660d16f4). The default version 2.21.1 at the time didn't really support aarch64, as shown by the autobuilder error reference in that commit. binutils has now had support for aarch64 since 2.23, but was never re-enabled for aarch64. All of the binutils versions currently supported by Buildroot (oldest being 2.24) support aarch64, so we can now enable it without any restrictions. This same patch also touches the dropwatch, lightning and oprofile packages which all select binutils and had the 'depends on !aarch64' to keep Kconfig consistent. They are now re-enabled for aarch64 as well. They are changed in this same patch so that Kconfig is kept consistent and doesn't end up having them disabled in a commit which only has the binutils change applied. lightning has other explicit arch dependencies so it is not actually yet available in aarch64, but at least the dependency on !aarch64 because of binutils is not needed anymore. Everything has been build tested with Buildroot and external toolchains. binutils and dropwatch work fine in a qemu target. oprofile doesn't seem to be supported in the qemu aarch64 processor but builds fine and seems to have some level of aarch64 support in the source, so there doesn't seem to be a reason to keep it disabled in Kconfig. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-29 05:33:35 +02:00
depends on !BR2_nios2 # binutils
binutils: now depends on wchar binutils starting at least from 2.23 when build for target require uClibc configured with UCLIBC_HAS_WCHAR otherwise: libtool: link: [...] -o as-new [...] read.o: In function `read_symbol_name': read.c:(.text+0x3634): undefined reference to `mbstowcs' collect2: error: ld returned 1 exit status because "mbstowcs" is not available in the C library. Even though we're not yet using 2.23.2 as the default version, we will probably do it in the near future, so this commit doesn't bother with making the wchar dependency version-specific, and applies it to the binutils package as a whole. Fixes bug #6218 [Thomas: - more details in the commit log. - add comment about the wchar dependency - propagate the dependency to dropwatch (and fix a mistake in the architecture dependencies of the comment) - propagate the dependency to oprofile.] Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2014-10-28 23:19:18 +01:00
depends on BR2_USE_WCHAR # binutils
oprofile: not available on Microblaze Commit c45979c732cb610ad5d54e23dd7d4d49e519d45b marked OProfile as not available on the Xtensa architecture, due to the lack of memory barrier operations. This commit does the same for the Microblaze architecture, for the same reason, which allows to fix the following autobuilder failure: http://autobuild.buildroot.org/results/9a872ddc906e9d552d30762e849a1b537b4e5095/ It is worth mentioning that most likely Xtensa and Microblaze are architectures implementing a strongly-ordered memory model, in which case we could define the memory barriers as no-ops. But until someone who actually cares about OProfile on Xtensa and Microblaze shows up, it's probably better to disable the package on those architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-24 21:59:37 +02:00
# no memory barrier functions
depends on !BR2_xtensa && !BR2_microblaze
libpfm4: needs thread support Fixes: http://autobuild.buildroot.net/results/73d736dd3c8a70358ef4b19a63dda46178cf8bf1/ Note that the propagation of the thread dependency to the oprofile package is a little bit non standard, because oprofile selects libpfm4 only on the PowerPC architecture. So we ensure the thread dependency is only enforced on PowerPC, and a separate comment is displayed when thread support is not available, but the PowerPC architecture is used. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-12-03 20:27:18 +01:00
# libpfm4 is needed on PowerPC, and requires thread support
oprofile: add missing indirect dependency on NPTL for PPC [Peter: also adjust comment dependencies] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-02-04 01:34:09 +01:00
depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL || !BR2_powerpc
add oprofile
2008-04-24 18:54:29 +02:00
help
OProfile is a system-wide profiler for Linux systems,
capable of profiling all running code at low overhead.
OProfile is released under the GNU GPL.
It consists of a kernel driver and a daemon for collecting
sample data, and several post-profiling tools for turning
data into information.
OProfile leverages the hardware performance counters of the
CPU to enable profiling of a wide variety of interesting
statistics, which can also be used for basic time-spent
profiling. All code is profiled: hardware and software
interrupt handlers, kernel modules, the kernel, shared
buildroot: remove trailing spaces for i in `find -name 'Config*' -o -name 'Makefile*' -o -name '*.mk'`; do sed -i 's/ \+$//' $i; done
2008-08-04 21:07:05 +02:00
libraries, and applications.
package/: depend on toolchain C++ config, don't use select select should only be used for package (library) dependencies.
2009-01-26 20:19:10 +01:00
binutils: now depends on wchar binutils starting at least from 2.23 when build for target require uClibc configured with UCLIBC_HAS_WCHAR otherwise: libtool: link: [...] -o as-new [...] read.o: In function `read_symbol_name': read.c:(.text+0x3634): undefined reference to `mbstowcs' collect2: error: ld returned 1 exit status because "mbstowcs" is not available in the C library. Even though we're not yet using 2.23.2 as the default version, we will probably do it in the near future, so this commit doesn't bother with making the wchar dependency version-specific, and applies it to the binutils package as a whole. Fixes bug #6218 [Thomas: - more details in the commit log. - add comment about the wchar dependency - propagate the dependency to dropwatch (and fix a mistake in the architecture dependencies of the comment) - propagate the dependency to oprofile.] Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2014-10-28 23:19:18 +01:00
comment "oprofile needs a toolchain w/ C++, wchar"
oprofile: disable on xtensa Missing memory barrier definition. Fixes http://autobuild.buildroot.net/results/df7/df797a81111fa15de9337adefca05cbac156d0b2/. Also, add nios2 to the dependencies comment while at it. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-12-30 11:00:07 +01:00
depends on BR2_USE_MMU
binutils: enable as target package for aarch64 binutils got disabled as a target package for aarch64 back in Buildroot 2012.11 (commit 660d16f4). The default version 2.21.1 at the time didn't really support aarch64, as shown by the autobuilder error reference in that commit. binutils has now had support for aarch64 since 2.23, but was never re-enabled for aarch64. All of the binutils versions currently supported by Buildroot (oldest being 2.24) support aarch64, so we can now enable it without any restrictions. This same patch also touches the dropwatch, lightning and oprofile packages which all select binutils and had the 'depends on !aarch64' to keep Kconfig consistent. They are now re-enabled for aarch64 as well. They are changed in this same patch so that Kconfig is kept consistent and doesn't end up having them disabled in a commit which only has the binutils change applied. lightning has other explicit arch dependencies so it is not actually yet available in aarch64, but at least the dependency on !aarch64 because of binutils is not needed anymore. Everything has been build tested with Buildroot and external toolchains. binutils and dropwatch work fine in a qemu target. oprofile doesn't seem to be supported in the qemu aarch64 processor but builds fine and seems to have some level of aarch64 support in the source, so there doesn't seem to be a reason to keep it disabled in Kconfig. Signed-off-by: Erico Nunes <nunes.erico@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-29 05:33:35 +02:00
depends on !BR2_nios2 && !BR2_xtensa && !BR2_microblaze
binutils: now depends on wchar binutils starting at least from 2.23 when build for target require uClibc configured with UCLIBC_HAS_WCHAR otherwise: libtool: link: [...] -o as-new [...] read.o: In function `read_symbol_name': read.c:(.text+0x3634): undefined reference to `mbstowcs' collect2: error: ld returned 1 exit status because "mbstowcs" is not available in the C library. Even though we're not yet using 2.23.2 as the default version, we will probably do it in the near future, so this commit doesn't bother with making the wchar dependency version-specific, and applies it to the binutils package as a whole. Fixes bug #6218 [Thomas: - more details in the commit log. - add comment about the wchar dependency - propagate the dependency to dropwatch (and fix a mistake in the architecture dependencies of the comment) - propagate the dependency to oprofile.] Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2014-10-28 23:19:18 +01:00
depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR
libpfm4: needs thread support Fixes: http://autobuild.buildroot.net/results/73d736dd3c8a70358ef4b19a63dda46178cf8bf1/ Note that the propagation of the thread dependency to the oprofile package is a little bit non standard, because oprofile selects libpfm4 only on the PowerPC architecture. So we ensure the thread dependency is only enforced on PowerPC, and a separate comment is displayed when thread support is not available, but the PowerPC architecture is used. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-12-03 20:27:18 +01:00
oprofile: add missing indirect dependency on NPTL for PPC [Peter: also adjust comment dependencies] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-02-04 01:34:09 +01:00
comment "oprofile needs a toolchain w/ NPTL on PPC"
libpfm4: needs thread support Fixes: http://autobuild.buildroot.net/results/73d736dd3c8a70358ef4b19a63dda46178cf8bf1/ Note that the propagation of the thread dependency to the oprofile package is a little bit non standard, because oprofile selects libpfm4 only on the PowerPC architecture. So we ensure the thread dependency is only enforced on PowerPC, and a separate comment is displayed when thread support is not available, but the PowerPC architecture is used. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2013-12-03 20:27:18 +01:00
depends on BR2_USE_MMU && BR2_powerpc
oprofile: add missing indirect dependency on NPTL for PPC [Peter: also adjust comment dependencies] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-02-04 01:34:09 +01:00
depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL
Reference in New Issue Copy Permalink