On newer toolchains (glibc >= 2.20) _BSD_SOURCE behaviour was deprecated
in favour if the _DEFAULT_SOURCE macro. See man 7 feature_test_macros.
Add patch from Fedora to also consider _DEFAULT_SOURCE. Fixes:
http://autobuild.buildroot.net/results/9e2/9e2126b0e68d0d59d37616a268adb810efd8281a/
Signed-off-by: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This package consists of scripts that setup cgroups at boot without
doing any cgroup management or classification of tasks into cgroups
Signed-off-by: Niranjan Reddy <niranjan.reddy@rockwellcollins.com>
[Thomas:
- rename to cgroupfs-mount to match upstream
- add proper hash, since hashes should be added for github sourced
packages
- fix minor typos in the init script
- fix the license file information.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- Use the recently introduced BR2_TOOLCHAIN_HAS_ATOMIC boolean.
- Import an upstream patch to fix error handling when atomic operations
are not detected. Without this patch the build fails due to a syntax
error instead of showing the proper message.
- Add a patch to configure.ac to check if libatomic is needed and force
linking to it (we will attempt to submit this upstream).
- Disable build for SPARC64 because it fails due to a missing definition
of Atomic64.
On PowerPC, the __atomic_*() built-ins for 1-byte, 2-byte and 4-byte
types are available built-in. The corresponding built-ins for 8-byte
types, however, are implemented via libatomic, so requiring gcc >= 4.8.
In Buildroot, to simplify things, it was decided to require gcc 4.8 as
soon as the architectures has at least one __atomic_*() built-in variant
that requires libatomic.
Since protobuf most likely only uses the 1, 2 and 4-byte variants, it
*could* technically build with gcc 4.7. This is probably not a big deal,
and we can live with requiring gcc 4.8 on PowerPC to build protobuf. The
same restriction applies to SPARC.
The build for SPARC64 breaks even using the master branch of protobuf
due to undefined references to some NoBarrier_Atomic*() functions.
Signed-off-by: Henrique Marks <henrique.marks@datacom.ind.br>
Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit modifies the cairo, icu and webkitgtk24 packages to use
BR2_TOOLCHAIN_HAS_LIBATOMIC when appropriate.
Fixes:
http://autobuild.buildroot.net/results/ec4/ec4e48c0e4b8fa72d8bb7ef4ad67a166699c0b62/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Until now, we were assuming that whenever you have gcc 4.8, libatomic
is available. It turns out that this is not correct, since libatomic
will not be available if thread support is disabled in the toolchain.
Therefore, __atomic_*() intrinsics may not be available even if the
toolchain uses gcc 4.8.
To solve this problem, we introduce a BR2_TOOLCHAIN_HAS_LIBATOMIC
boolean, which indicates whether the toolchain has libatomic. It is
the case when you are using gcc >= 4.8 *and* thread support is
enabled. We then use this new BR2_TOOLCHAIN_HAS_LIBATOMIC to define
BR2_TOOLCHAIN_HAS_ATOMIC.
As explained in the comment, on certain architectures, libatomic is
technically not needed to provide the __atomic_*() intrinsics since
they might be all built-in. However, since libatomic is only absent in
non-thread capable toolchains, it is not worth making things more
complex for such seldomly used configuration.
Note that we are introducing the intermediate
BR2_TOOLCHAIN_HAS_LIBATOMIC option because it will be useful on its
own for certain packages.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: improve Config.in comment using a suggestion from Yann.]
While building libevas.so for the host-efl with luajit support, the link fail
when libluajit is build statically:
/usr/bin/ld: output/host/usr/lib/libluajit-5.1.a(ljamalg.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
output/host/usr/lib/libluajit-5.1.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Build luajit dynamically in order to build host-efl with luajit support.
Also, passing HOST_LDFLAGS is needed so that a proper rpath is added
to the resulting binaries. Note that it is expected to have
HOST_LDFLAGS assigned to TARGET_LDFLAGS, it's just that luajit has a
somewhat non-conventional naming of variables. This is needed to avoid
the following error from the rpath sanity check:
***
*** ERROR: package host-luajit installs executables without proper RPATH:
*** output/host/usr/bin/luajit
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove files that aren't used for runtime purposes.
Size savings delta +450 KB.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It was added to the networking category close to connman for the ability
to tweak connman features without going around (i.e. add support for
wifi and so on).
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove source schema files from target
(/usr/share/glib-2.0/schemas/*.dtd and *.xml) at target finalization
time.
This is because other packages install schemas as well to avoid
duplicating file removal efforts all around.
Add a schema compiler run on target finalization as well - we previously
didn't do this since not many packages use it, however the upcoming
connman-gtk package does require a valid gschemas.compiled to work
properly.
We also do this at target finalization to avoid each package handling
this on their own.
Purge some extra binaries and files from the target, like the schema
compiler to save additional space since they're unused at run time.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit c44cf2cc97.
Now that xtensa gas don't move literals into .init and .fini this fix is
no longer needed.
See upstream commit
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4111950f363221c4641dc2f33bea61cc94f34906,
which was backported to all supported binutils version, under the name
*-xtensa-fix-.init-.fini-literals-moving.patch.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
[Thomas: add more details in the commit log, as suggested by Yann
E. Morin, and using information provided by Max.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr: independently done a patch similar to the one
by Thomas]
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch adds the ability to compile and install the kernel
selftests into the target at /usr/lib/kselftests. The rationale behind
/usr/lib is that the selftests have subdirectories where they are
installed which makes them unsuitable to be placed in /usr/sbin as
this would result in /usr/sbin/kselftests/x/y/z. While the selftests
aren't libraries either, they don't achieve much as a standalone
binary so they can be considered to be a 'library of tests' making
/usr/lib sensible.
The selftests require that the kernel headers be installed into the
kernel build tree as some of the selftests have a hardcoded CFLAGS to
include kernel headers (CFLAGS += -I../../../../usr/include/). This is
most easily achieved by using the make ... headers_install inside the
kernel build dir.
This is likely to be a rarely used debugging/performance feature for
development and unlikely to be used in a production configuration.
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas:
- remove bash as a build dependency, it is only a runtime dependency.
- fix typo in the Config.in help text, and rewrap
- add missing 'depends on BR2_USE_MMU' dependency for the comment.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The optinal dependency on celt is not added, because we only have
celt-0.5.1 and jack2 requires celt >= 0.5.2 (even though it does look
for celt >= 0.5.0, it does not build with celt- < 0.5.2). Since we
cannot upgrade celt (for now), we just never make jack2 depend on
celt051, and it won't find it either, as it just searches for celt.pc
and we have celt051.pc.
As well, the dependency on eigen is only useful in conjunction with
gtkiostream, for which we do not have a package. So, we don't need to
depend on eigen.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
jack2 allows to use three modes:
- A legacy jackd service alone.
- A DBUS jackd service alone.
- A mixture between the standalone jackd and the DBUS jackd.
This patch adds the possibility to choose between these three modes,
while the legacy jackd was the only option before.
In addition, the jack_control tool is removed when the DBUS jackd is not
available, as this tool is used to control it.
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
[yann.morin.1998@free.fr:
- rebase
- only use two booleans, not a choice
- python is a runtime-only dependency
- use python3 if enabled, fallback to python
- simplify post-install condition
]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas: fix minor typo.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For wayland 1.10+ they're split from wayland core and required by
weston.
Hide it behind the wayland package since it's useless independently even
though it can be "built" and installed.
And it makes no sense to install to target since they are DTDs used at
build-time.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
wayland-scanner host/cross support is now native so drop the funky
trick.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Move it outside x11r7 scope since it can be built without it with a few
patches (sent upstream via github pull request).
Motivation is simple, it's a dependency for newer gtk3 versions which
can work with a wayland or broadway backend, and having a full x11 stack
is pointless for that scenario.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
[Thomas: split the first patch into four separate patches, since
that's how they were submitted upstream.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We need to match xserver here, since we need glamor support there in
order to enable it here, hence need to match the dependencies.
For xserver it needs dri3proto+libepoxy, however if only libepoxy is
present then glamor would be disabled for the server but enabled for the
driver, leading to build failure.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds the option to select the Cortex-M4 ARM core, in the
same family as Cortex-M3. This will be useful to enable the internal
toolchain backend for this ARM core, and provide some defconfigs for
Cortex-M4 platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Cortex-M cores only support Thumb-2, not Thumb. In fact, Thumb-2
is a superset of Thumb, and we could have a single option for both in
Buildroot, since -mthumb on ARMv4/v5 means original Thumb, while
-mthumb on ARMv7 means Thumb 2. However, for clarity, it makes sense
to have two separate options. But in this case, Cortex-M3 should not
advertise that it supports Thumb, as in fact selecting Thumb would
generate Thumb-2 code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
All ARM cores should select a BR2_ARM_CPU_* option. Currently, the
cortex-m3 does not, which this commit fixes by introducing a
BR2_ARM_CPU_ARMV7M option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Ethernet is not working, but at least you get a shell and
can test applications for m68k.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This allows to build a m68k toolchain with uClibc.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Plugins want to use dlopen even when configured with --disable-shared.
Add --disable-plugins when STATIC_LIBS is selected.
Fixes:
http://autobuild.buildroot.net/results/a59e5858d777dcee3d8f7fb6e82ee4735b520155/
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This option is needed to fix the Kodi build with older host gcc
versions.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
