Following the removal of eglibc support, this commit replaces all
occurences of "(e)glibc" by just "glibc". Most of the occurences are in
package Config.in comments.
In addition, when the form "an (e)glibc ..." was used, it is replaced by
"a glibc ...".
[Peter: add new efi* packages, s/uclibc/uClibc as suggested by Romain,
systemd / liquid-dsp tweaks as suggested by Yann]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As Thomas puts it:
The comment can only be visible when a toolchain that is *not*
uclibc and *not* glibc is used. I.e, the comment is now only visible
when musl is used. Which is not what we want.
Indeed, I completely borked the conditions. When a glibc or uClibc
toolchain is selected, the comment is entirely hidden, and we don;t get
the extra requirements (wchar, !static).
Fix that with the solution proposed by Thomas.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that largefile is mandatory removes package dependencies and
conditionals.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 elfutils package provides a more recent version of the libelf, so
let's use it. It will allow to remove the libelf package and to avoid
conflicts with two packages providing the same library.
[Peter: adjust toolchain options comment to match]
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>
[Thomas:
- remove empty newline at the end of Config.in
- use lowercase for the package name in the comment header
- reword the comment explaining why autoreconf is needed
- add optional dependency on libftdi, which avrdude can use
- remove avrdude.conf.bak file from /etc]
Signed-off-by: Wojciech M. Zabolotny <wzab01@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
