Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed
from "prefer static libraries when possible" to "use only static
libraries". The former semantic didn't make much sense, since the user
had absolutely no control/idea of which package would use static
libraries, and which packages would not. Therefore, for quite some
time, we have been starting to enforce that BR2_PREFER_STATIC_LIB
should really build everything with static libraries.
As a consequence, this patch renames BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS, and adjust the Config.in option accordingly.
This also helps preparing the addition of other options to select
shared, shared+static or just static.
Note that we have verified that this commit can be reproduced by
simply doing a global rename of BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Even when doing static builds, a shared library is built. This causes a
build failure under some circumstances, for instance when building for
MIPS + uClibc + static.
After asking upstream if it would be possible to add a configure option
to not build the shared library, the answer was that doing a static
build is not a good idea. Here is a small snippet of the conversation:
"Note that fully static builds are problematic. elfutils uses dlopen to
open the EBL backends (the CPU-specific support snippets), so even if
you link statically, the final binaries are still considerably dynamic."
Related:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-November/004223.html
Fixes:
http://autobuild.buildroot.net/results/691/6913f5af6519463fbed39ef37b6a40ecf6a67b54/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The libelf is currently provided by 2 packages libelf and
elfutils. The first package provides an old version of the libelf
which is no more compatible with a recent version of ltrace. This
patch removes the dependency on the libelf package and only keep the
elfuils package which provides the accurate version of libelf for
ltrace.
It will also allow to remove the libelf package and to avoid conflicts
with two packages providing the same library.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ltrace currently doesn't build on mips/mipsel, and it's an upstream
issue that has been reported. Until it get fixed, let's disable ltrace
for mips/mipsel.
Fixes:
http://autobuild.buildroot.org/results/43a/43a8fc7075f52eab74ebfee4c9f25dd2b886e75e/
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes build error in elfutils
http://autobuild.buildroot.net/results/37f/37f87ad7ba087d42d0001f55305f7468c2a172b6/
eblwstrtab.c:(.text+0x43): undefined reference to `wmempcpy'
eblwstrtab.c:(.text+0x1ba): undefined reference to `wcslen'
eblwstrtab.c:(.text+0x2df): undefined reference to `wmemcmp'
because ltrace did not take into account that elfutils depends on
BR2_LARGEFILE & BR2_USE_WCHAR. This is also visible here:
wget http://autobuild.buildroot.net/results/37f/37f87ad7ba087d42d0001f55305f7468c2a172b6/defconfig
make defconfig BR2_DEFCONFIG=defconfig
warning: (BR2_PACKAGE_LTRACE) selects BR2_PACKAGE_ELFUTILS which has unmet direct
dependencies (BR2_LARGEFILE && BR2_USE_WCHAR && !BR2_avr32 && !BR2_bfin)
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ltrace 0.7.3 is the latest release but it is actually broken on ARM
since PTRACE_SINGLESTEP emulation has been removed, see:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=425fc47adb5bb69f76285be77a09a3341a30799e
It fails with:
PTRACE_SINGLESTEP: Input/output error
Using master solves that until a new release is made.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
First switch the architecture availability to positive logic since it's
cleaner and avoids issues when new ones are introduced.
Then look at the source for the available ones at sysdeps/linux-gnu/...
aarch64 -> NULL
arc -> NULL
arm -> hardcoded to little endian, so no armeb
avr32 -> NULL
blackfin -> NULL
microblaze -> NULL
mips -> little/big endian handled but not for 64 bits
nios2 -> NULL
ppc -> OK
sh -> NULL
sparc -> OK
x86 -> Both i386 and x86_64 handled
xtensa -> NULL
Fixes:
http://autobuild.buildroot.net/results/cd2/cd24e7b6f863ab413d76ca7a81bd357ddf1dc4f7/
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Xtensa architecture had been removed because it required special
handling and depended on additional directories and files that became
obsolete over time. This change is more aligned to other architectures.
[Thomas: rebased on top of the "arch: improve definition of gcc mtune,
mcpu, etc." patch].
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As stated in commit 555c2585bf, the
Xtensa architecture has been introduced in 2009 and never changed
since its initial introduction. It requires some special handling that
is a bit annoying, and despite our call to the initial developers, and
the announcement of the deprecation of the architecture during the
2012.05, nothing has happened. Therefore, drop support for this
architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: me
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Has been marked as broken for more than 1 year, with no indication
that anyone cares, and it needs a bunch of special handling.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
