mpd uses __atomic_*() built-ins, but forgets to link with -latomic
when needed, so this commit adds a patch that ensures it will link
with libatomic, and adds a dependency on BR2_TOOLCHAIN_HAS_ATOMIC.
Fixes:
http://autobuild.buildroot.net/results/e2207280f3a177e12dba502b1c01f5aeb431d04c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit replaces 0002-musl-gcc5-fixes.patch by a backport of 3
upstream commits. It also renames
0001-thread-Name-include-stdio.h-for-prctl-as-well.patch to have the
sequence number 0004, so that it applies after the backported upstream
patches (since this patch is not upstream yet).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The tarball contains a working configure script, therefore removed
autoreconf.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
From [1]:
With version 2.0, the source code has been cleanly split into
an application-oriented user library and a time-critical stack
driver. The latter may be moved to a dedicated communication
processor or into a kernel module to deliver enhanced
performance while still keeping the API in user space.
This new version break the API used in the v1.x but
this is a complete rewrite of the Powerlink EPSG DS 301
implementation. The v1.x is deprecated anyway.
The new build system has been split in several CMake projects
which makes it difficult to package with the Buildroot CMake
infra. So add a top level CMakeLists.txt to build each
openpowerlink component without having to package each of them
in a separate Buildroot packages. Also we need to fix the
build system to support the top level CMake build.
[1] http://sourceforge.net/projects/openpowerlink/
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas:
- rename patches to not contain the [FIX] part in their title.
- rewrap Config.in help text
- rename "openPOWERLINK stack type" to "stack type"
- rename ""openpowerlink demos" to "demos"]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
kbd currently doesn't build against musl, due to some issues which
have already been fixed upstream. This commit therefore bumps to the
latest upstream version 2.0.3 to fix the musl build. In order to do
so, this commit also:
- backports a patch that makes building tests optional, which allows
to avoid a dependency on the check package
- updates the libintl patch to work with the latest upstream
Fixes:
http://autobuild.buildroot.net/results/535/5357953e763a1ac4f17332abac54ce2946629a41/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The build error was not yet found by the autobuilders:
output_alsa.c: In function ‘output_init_alsa’:
output_alsa.c:865:10: error: ‘M_TRIM_THRESHOLD’ undeclared (first use in this function)
mallopt(M_TRIM_THRESHOLD, -1);
^
output_alsa.c:865:10: note: each undeclared identifier is reported only once for each function it appears in
output_alsa.c:866:10: error: ‘M_MMAP_MAX’ undeclared (first use in this function)
mallopt(M_MMAP_MAX, 0);
^
This commit adds a patch fixing this build error by making the
mallopt() usage conditional on __GLIBC__.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Thomas: only enclose the mallopt() call in __GLIBC__, use Git to
format the patch, improve the commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch also fixes the broken download of the previous version.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
setup3.py will be automatically invoked from setup.py,
if executing on Python 3 platform.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
According to http://sourceforge.net/projects/libcue the project moved
to github.com, all source tarballs were removed from Sourceforge.
Adjust project and download URLs, update hash and remove
0001-_unused-fix.patch because there is no trace of "__unused" in the
upstream tarball anymore, the patch fails to apply.
Add autoreconf because the new upstream tarball does not contain a
configure script, autoreconf also needs a tweak because it fails when
config/ is not present.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The build error is known upstream
http://sourceforge.net/p/openipmi/patches/26/
and was not yet caught by our autobuilders:
ui.c: In function ‘get_ip_addr’:
ui.c:340:5: error: unknown type name ‘u_int32_t’
u_int32_t addr;
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add upstream commit fixing a build error not yet been found by the
autobuilders:
pstree.c: In function ‘get_threadname’:
pstree.c:798:15: error: ‘PATH_MAX’ undeclared (first use in this function)
char path[PATH_MAX + 1];
^
pstree.c:798:15: note: each undeclared identifier is reported only once for each function it appears in
pstree.c:798:10: warning: unused variable ‘path’ [-Wunused-variable]
char path[PATH_MAX + 1];
^
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The build error was not yet found by the autobuilders:
In file included from main.c:46:0:
rand.h:31:9: error: unknown type name ‘u_int32_t’
typedef u_int32_t u_rand_t;
^
<builtin>: recipe for target 'main.o' failed
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds a patch to the iprutils to fix the build with the
musl C library.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Thomas: reformatted the patch with Git, added a better commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Upstream now provides a new autoconf-based build system, therefore
our patches for Makefile are not needed anymore.
We adapt the gettext patch to make sure that the configure script
doesn't check for libintl.h, and we add an additional patch to fix the
libm check.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Thomas: rework patches.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
samba4 uses the __sync_fetch_and_add_4() atomic built-in, so it should
depend on BR2_TOOLCHAIN_HAS_SYNC_4 in order to avoid build failures on
architectures not providing this atomic built-in.
Fixes:
http://autobuild.buildroot.org/results/0d0fd9d2a132a40a840bea5df59c35d8573ebf45/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Having the host version may allow post-image scripts to encrypt the
resulting image with aespipe (and decrypt it in the update tool on the
target).
Signed-off-by: Ariel D'Alessandro <ariel@vanguardiasur.com.ar>
[Thomas: rewrap Config.in help text, tweak commit title.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Also switch upstream URL to new host as mentioned on old site.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The build error has not yet been found by the autobuilders:
operf.cpp: In function ‘int __delete_old_previous_sample_data(const char*, const stat*, int, FTW*)’:
operf.cpp:862:10: error: ‘FTW_STOP’ was not declared in this scope
return FTW_STOP;
^
operf.cpp:864:10: error: ‘FTW_CONTINUE’ was not declared in this scope
return FTW_CONTINUE;
^
operf.cpp: In function ‘void convert_sample_data()’:
operf.cpp:899:41: error: ‘FTW_ACTIONRETVAL’ was not declared in this scope
int flags = FTW_DEPTH | FTW_ACTIONRETVAL;
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Upstream source repo switched to github.com. Since the last release
dating back to 2014 no new tarball was released so we switch to the
latest github commit.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The boost package adds a dependency on the libiconv package when
boost-locale is selected but locale support is not available in the
toolchain. However, it forgets to select BR2_PACKAGE_LIBICONV in this
situation, causing the following build failure:
http://autobuild.buildroot.org/results/ab1809f4fa8cf29208f9503edd90aca87fe397c2/
This commit fixes this mistake by adding the necessary select
BR2_PACKAGE_LIBICONV.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
openal can uses __atomic_*() intrinsics when available, or fall-back
on __sync_*() built-ins. This commit adjusts the package to take into
account for those dependencies, and makes sure we link against
libatomic when gcc >= 4.8 so that the __atomic_*() intrinsics can be
used on all architectures.
Fixes:
http://autobuild.buildroot.org/results/314fb8da3ca87984e9240d67ff233e2f999ae89e/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
glog can optionally use atomic __sync built-ins. However, its
configure script only checks for the availability of the 4-byte
variant, but the code also uses the 1-byte variant. While this works
on most architectures, it does not on architectures that implement
only the 4-byte variant, such as Microblaze. So if the architecture
does not implement the 1-byte variant, we hint the configure script
that atomic built-ins should not be used.
Fixes:
http://autobuild.buildroot.org/results/bedebd594c283adf39374c9a9f44432e5d6cbff7/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The msgpack source code indeed checks for the 4 bytes __sync built-in,
so this commit switches the package from a BR2_ARCH_HAS_ATOMICS
dependency to a BR2_TOOLCHAIN_HAS_SYNC_4 dependency.
python-msgpack, a reverse dependency of msgpack, is changed in the
same way.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
thrift builds perfectly fine on SPARC, which doesn't implement any of
the __sync built-ins, so we can get rid of the BR2_ARCH_HAS_ATOMICS
dependency.
The dependency on atomic operations originated in commit
1aaa14d84f ("thrift: disable for ARC"),
but there was no reference to any autobuilder failure. Our testing
with an ARC toolchain that doesn't have atomics shows that thrift
builds just fine, and code inspection also shows no usage of
__sync_*() built-ins. At the time of the commit, the thrift version
was 0.9.1, which also did not contain any __sync_*() call.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr: build-tested on an ARC toolchain without
atomics, with CPU 770D]
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
squid can use the __sync built-ins when available, but uses an
AC_TRY_RUN autoconf tests to check their availability, which isn't
compatible with cross-compilation. Due to this, squid.mk is already
hinting the configure script about this by passing
squid_cv_gnu_atomics=yes/no depending on the availability of atomic
operations.
So far, squid.mk was assuming that BR2_ARCH_HAS_ATOMICS &&
BR2_ARCH_IS_64 was needed, since 8 bytes __sync built-ins are
used. However, this was a bit too restrictive, since certain 32 bits
architectures (ARM, x86) do provide 8 bytes __sync built-ins.
So, instead of using BR2_ARCH_HAS_ATOMICS, we now rely on
BR2_TOOLCHAIN_HAS_SYNC_4 and BR2_TOOLCHAIN_HAS_SYNC_8, since both 4
bytes and 8 bytes __sync built-ins are tested by the autoconf test.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This commit handles the reverse dependency tree of cairo in terms of
atomic dependencies. There are two main changes:
- cairo in fact no longer needs atomic operations. It can perfectly
build without any __sync built-in, as was tested using an ARC
toolchain without atomics, and a SPARC toolchain. Optionally, Cairo
can use the __atomic builtins provided by gcc >= 4.7, so support
for this is added as well. Thanks to this change, the
BR2_ARCH_HAS_ATOMICS dependency is removed from cairo and all its
reverse dependencies.
- harfbuzz does require the __sync built-in for 4 bytes integers, so
we add a dependency on BR2_TOOLCHAIN_HAS_SYNC_4 to harfbuzz and all
its reverse dependency, the main one being the pango package. Due
to this, the vast majority of gtk-related packages are moved to a
dependency on BR2_ARCH_HAS_ATOMICS (which used to be due to cairo)
to a dependency on BR2_TOOLCHAIN_HAS_SYNC_4 (due to pango ->
harfbuzz).
In detail:
- cairo
Remove BR2_ARCH_HAS_ATOMICS dependency, link against -latomic when
gcc >= 4.8 in order to use the __atomic functions.
- harfbuzz
Add dependency on BR2_TOOLCHAIN_HAS_SYNC_4
- cairomm, gst-plugins-good, gst1-plugins-good, libgdiplus,
libsvg-cairo, weston
Remove BR2_ARCH_HAS_ATOMICS dependency (since cairo no longer needs
atomics)
- enlightenment, cwiid, gst-plugins-bad, gst-plugins-base,
gst1-plugins-bad, gst1-plugins-base, gtkmm3,
libevas-generic-loaders, libfm, libgail, libgtk2, libgtk3, librsvg,
openbox, opencv, opencv3, pango, pangomm, pcmanfm, pinentry,
rrdtool, webkit, webkitgtk24, xscreensaver
Switch from a BR2_ARCH_HAS_ATOMICS dependency to a
BR2_TOOLCHAIN_HAS_SYNC_4 (they depend on pango, harfbuzz, gtk, or
some other related package)
- directfb
Remove BR2_ARCH_ATOMICS dependency of the BR2_PACKAGE_DIRECTFB_SVG
(since cairo can build without atomics), but add a
BR2_TOOLCHAIN_HAS_SYNC_4 dependency on BR2_PACKAGE_DIRECTFB itself
since it does use __sync built-ins. This replaces the !BR2_sparc
dependency.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gauche does not build on sparc64, it fails with:
No rule to make target 'sparc_mach_dep.lo', needed by 'libgc.la'
On Sparc, it first fails with the usual "membar" assembler issue which
comes from gauche's internal version of libatomic_ops. However, even
passing -DAO_NO_SPARC_V9 like we do for libatomic_ops is not
sufficient, as we fall into the same build problem as on sparc64.
Consequently, this commit disables the gauche package on the sparc and
sparc64 architectures.
Since it uses its own libatomic_ops copy, and libatomic_ops does not
have any dependency on atomic built-ins, we also remove the
BR2_ARCH_HAS_ATOMICS dependency. It was originally added to prevent
gauche from being built on sparc, but this will no longer happen.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
libtorrent uses 1 bytes and 4 bytes __sync built-ins, so let's use the
appropriate BR2_TOOLCHAIN_HAS_SYNC_x symbols instead of
BR2_ARCH_HAS_ATOMICS. The rtorrent package, which is a reverse
dependency of libtorrent, gets fixed as well.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr: build-tested on an ARC toolchain without
atomics, with CPU 770D]
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
