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>
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>
When a package A depends on config option B and toolchain option C, then
the comment that is given when C is not fulfilled should also depend on B.
For example:
config BR2_PACKAGE_A
depends on BR2_B
depends on BR2_LARGEFILE
depends on BR2_WCHAR
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
This comment should actually be:
comment "A needs a toolchain w/ largefile, wchar"
depends on BR2_B
depends on !BR2_LARGEFILE || !BR2_WCHAR
or if possible (typically when B is a package config option declared in that
same Config.in file):
if BR2_B
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
[other config options depending on B]
endif
Otherwise, the comment would be visible even though the other dependencies
are not met.
This patch adds such missing dependencies, and changes existing such
dependencies from
depends on BR2_BASE_DEP && !BR2_TOOLCHAIN_USES_GLIBC
to
depends on BR2_BASE_DEP
depends on !BR2_TOOLCHAIN_USES_GLIBC
so that (positive) base dependencies are separate from the (negative)
toolchain dependencies. This strategy makes it easier to write such comments
(because one can simply copy the base dependency from the actual package
config option), but also avoids complex and long boolean expressions.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(untested)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch lines up the comments in Config.in files that clarify which
toolchain options the package depends on.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
Based on patch by Benoit Mauduit. Now that we can build binutils for
the target with external toolchains, oprofile is also available.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
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>
oprofile depends on binutils_target, but binutils_target fails to
build with external toolchains because the binutils version has not
been choosen. As the fix is not trivial, let's just disable oprofile
in external toolchain builds for the moment.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
