This config has no prospect of going into the future (by using DTS), and
qemu doesn't do a good job at emulating it (networking problems), so
drop it.
All of the ARM SMP testing duties are now in the vexpress defconfig
which is better suited/supported.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
configs/qemu: update arm-vexpress instructions for SMP
We can use the vexpress arm defconfig to test SMP features in Qemu.
So document the necessary invocation changes to account for this, in
preparation of the arm nuri defconfig removal.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Martin Bark [Sat, 30 Jan 2016 14:51:00 +0000 (14:51 +0000)]
package/nodejs: remove version choice
Remove the choice of nodejs version. Now automatically pick nodejs 0.10.x
for armv5 architectures only and the latest nodejs for all other
supported architectures.
Note that the removal of BR2_PACKAGE_NODEJS_5_X is not handled in
Config.in.legacy because buildroot has never been released with this
option included.
Signed-off-by: Martin Bark <martin@barkynet.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Martin Bark [Sat, 30 Jan 2016 14:50:59 +0000 (14:50 +0000)]
package/nodejs: bump to version 5.5.0
Patches from 5.3.0 have been copied over with the following exceptions:
- Removed 0005-Fix-crash-in-GetInterfaceAddresses.patch as this has
been applied upstream
- Renamed 0006-Fix-support-for-uClibc-ng.patch to
0005-Fix-support-for-uClibc-ng.patch
Signed-off-by: Martin Bark <martin@barkynet.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Make it depend explicitly on BR2_PACKAGE_LIBGTK3_X11 (the X11 backend
option) to avoid the checker from complaining.
Also add a comment about yad requiring the X11 backend otherwise it's
ambiguous if a user has libgtk3 enabled with broadway/wayland and the
comment shows up. Fixes:
http://autobuild.buildroot.net/results/84d/84d97bbcc0ea4f8eaa50dd25bf9ee8fdee4b937f/
Also cleanup some tiny whitespace in the package mk file.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Yann E. MORIN [Sun, 7 Feb 2016 21:34:29 +0000 (22:34 +0100)]
core: add a make target to check the dependencies
Add a make target that will checks the dependencies of all packages.
This will currently only detect circular dependencies, but more tests
can be added later if need be.
This can then be used in the autobuilders to automatically report
dependency issues.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Yann E. MORIN [Sun, 7 Feb 2016 21:34:28 +0000 (22:34 +0100)]
support/graph-depends: teach it to only check dependencies
Add an option to graph-depends to only do the dependency checks and not
generate the dot program.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, if there is a circular dependency in the packages, the
graph-depends script just errors out with a Python RuntimeError which is
not caught, resulting in a very-long backtrace which does not provide
any hint as what the real issue is (even if "RuntimeError: maximum
recursion depth exceeded" is a pretty good hint at it).
We fix that by recursing the dependency chain of each package, until we
either end up with a package with no dependency, or with a package
already seen along the current dependency chain.
We need to introduce a new function, check_circular_deps(), because we
can't re-use the existing ones:
- remove_mandatory_deps() does not iterate,
- remove_transitive_deps() does iterate, but we do not call it for the
top-level package if it is not 'all'
- it does not make sense to use those functions anyway, as they were
not designed to _check_ but to _act_ on the dependency chain.
Since we've had time-related issues in the past, we do not want to
introduce yet another time-hog, so here are timings with the circular
dependency check:
$ time python -m cProfile -s cumtime support/scripts/graph-depends
[...] 28352654 function calls (20323050 primitive calls) in 87.292 seconds
The cumulative time spent in check_circular_deps is just below 0.5s,
which is largely less than 1% of the total run time.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Yann E. MORIN [Sun, 7 Feb 2016 21:34:26 +0000 (22:34 +0100)]
core: catch failures in graph-depends
Currently, we generate the dependency graph in a single command, piping
the stdout of support/scripts/.graph-depends to the stdin of dot.
Unfortunately, this means we can't catch a failure of graph-depends, as
the shell can only treturn the exit code of the last command in a pipe.
Still, we do want to keep the output of graph-depends, and we in fact do
keep it by mean of a tee.
graph-depends has just gained the ability to generate its output to a
file, so we break the pipe in two differnet commands, so we can bail out
on graph-depends errors.
Do that for the two call sites.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Yann E. MORIN [Sun, 7 Feb 2016 21:34:25 +0000 (22:34 +0100)]
support/graph-depends: add option to specify output file
Currently, graph-depends outputs the dotfile program to stdout, and uses
stderr to trace the dependencies it is currently looking for.
Redirection was done because the output was directly piped into the dot
program to generate the final PDF/SVG/... dependency graph, but that
meant that an error in the graph-depends script was never caught
(because shell pipes only return the final command exit status, and an
empty dot program is perfectly valid so dot would not complain).
Add an option to tell graph-depends where to store the generated dot
program, and keep stdout as the default if not specified.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Samuel Martin <s.martin49@gmail.com>
[Thomas: rename metavar from DOT_FILE to OUT_FILE for consistency with
the rest of the new option naming.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The cups -> avahi dependency makes sense, as cups would be able to use
Bonjour and mDNS to find printers, so we want to keep that dependency.
The libgtk2 -> cups and libgtk3 -> cups dependencies also make sense, to
be able to offer cups in the print dialogs.
However, the avahi -> libglade and avahi -> libgtk3 dependencies do not
really make sense. As Thomas puts it:
The avahi GUI programs seem really useless to me. On Debian/Ubuntu
distributions, they are not even packaged within the main avahi
packages, but as separate packages, probably indicating that they
are not very commonly used.
So, we drop the avahi -> libglade and avahi -> libgtk3 dependencies, to
break the circular dependency chain.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas: add comment in the .mk file.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bernd Kuhls [Sat, 30 Jan 2016 08:31:40 +0000 (09:31 +0100)]
package/musepack: fix musl build
This commit adds two patches needed to fix musl related build issues
in musepack: a missing <sys/select.h> inclusion, and an inclusion of
<fpu_control.h> that should be made conditional on __GLIBC__.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Thomas: split the patch in two patches, add proper patch
description.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Keep arm_nuri on 3.10.x for the usual reasons.
Keep mips & mipsel (32 bits) on 4.3.x because 4.4.x fails to boot
properly (kernel stuck after the CPU cache info).
Results table:
Defconfig Kernel Qemu Network Status
--------------------------------------------------------------
aarch64_virt 4.4.1 2.3.0 YES OK
arm_nuri 3.10.96 2.3.0 YES(1) OK most times(2)
arm_versatile 4.4.1 2.3.0 YES OK
arm_vexpress 4.4.1 2.3.0 YES OK
microblazebe 4.4.1 2.3.0 YES OK
microblazeel 4.4.1 2.3.0 YES OK
mips64el_malta 4.4.1 2.3.0 YES OK
mips64_malta 4.4.1 2.3.0 YES OK
mipsel_malta 4.3.5 2.3.0 YES OK (4)
mips_malta 4.3.5 2.3.0 YES OK (4)
ppc_g3beige 4.4.1 2.3.0 YES OK
ppc_mpc8544ds 4.4.1 2.3.0 YES OK
ppc_virtex_ml507 4.4.1 2.3.0 NO OK
ppc64_pseries 4.4.1 2.3.0 YES OK
sh4 4.4.1 2.3.0 YES OK
sh4eb 4.4.1 2.3.0 NO(3) OK
sparc_ss10 4.4.1 2.3.0 YES OK
sparc64_sun4u 4.4.1 2.3.0 YES OK
sparc_sun4u 4.4.1 2.3.0 YES OK
x86 4.4.1 2.3.0 YES OK
x86_64 4.4.1 2.3.0 YES OK
xtensa_lx60 4.4.1 2.3.0 YES OK
(1) - Supposed to work but broken, probably Qemu emulation issue
(2) - In like 1/3 starts it fails to work properly
(3) - Probably an endian issue with 8139 emulation/driver
(4) - Kernel stuck at cpu cache details from 4.4 - 4.4.1
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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.
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>
Removing PROCPS_NG_CONF_OPTS completely leads to binaries being
installed to /usr/bin, we still have to define a custom --exec-prefix
to get binaries in /bin:
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Thomas: rename patch and improve its description.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Romain Naour [Sun, 7 Feb 2016 16:56:56 +0000 (17:56 +0100)]
package/openpowerlink: bump to v2.2.2
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.
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
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>
Leverage the CSV files produces by size-stats (make graph-size) to allow
for a comparison of rootfs size between two different buildroot
compilations.
The script takes the file-size CSV files of two compilations as input, and
produces a textual report of the differences per package.
Using the -d/--detail flag, the report will show the file size changes
instead of package size changes.
The -t/--threshold option allows to ignore file size differences smaller
or equal than the given threshold (in bytes).
Example output is:
Size difference per package (bytes), threshold = 0
--------------------------------------------------------------------------------
-8192 busybox
228572 added dmalloc
301584 added jq
--------------------------------------------------------------------------------
521964 TOTAL
Bernd Kuhls [Sat, 30 Jan 2016 14:21:55 +0000 (15:21 +0100)]
package/libcue: update upstream URL
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>
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas:
- Rework patch 0001-padsp-Make-it-compile-on-musl.patch to put
Bernd's comment and SoB *after* the original commit log.
- Rework patch 0002-musl-fixes.patch for the same reason, and also to
remove the xlocale.h part, which has already been fixed upstream.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bernd Kuhls [Sun, 31 Jan 2016 12:16:05 +0000 (13:16 +0100)]
package/psmisc: fix musl build
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];
^
Bernd Kuhls [Sun, 31 Jan 2016 20:44:14 +0000 (21:44 +0100)]
package/wipe: fix musl build
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
Bernd Kuhls [Sun, 7 Feb 2016 13:13:07 +0000 (14:13 +0100)]
package/iprutils: add patch to fix musl build
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>
samba4: add dependency on BR2_TOOLCHAIN_HAS_SYNC_4
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.
Bernd Kuhls [Fri, 5 Feb 2016 21:50:26 +0000 (22:50 +0100)]
package/oprofile: fix musl build
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>
Bernd Kuhls [Sat, 6 Feb 2016 12:02:27 +0000 (13:02 +0100)]
package/knock: bump version to 0.7.8
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>
Add a dependency on !BR2_STATIC_LIBS, since <dlfcn.h> is used. While
we're at it, we also fix the comment which was lacking the BR2_USE_MMU
dependency.
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:
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.
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.
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 1aaa14d84f1c920423ed0286b78f64a2b4b2b575 ("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.
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: disable on SPARC(64), remove atomics dependency
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: use the proper BR2_TOOLCHAIN_HAS_SYNC_x symbols
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>
Since the apache package was introduced,
--enable-nonportable-atomics=yes was passed when
BR2_ARCH_HAS_ATOMICS. However, Apache doesn't take this option: it
only passes it down when building the APR library. But since we're
building APR separately, this statement had no effect.
So this commit removes the useless code from the Apache package, and
instead adds the appropriate logic to the apr package, using the new
BR2_TOOLCHAIN_HAS_SYNC_x symbols rather than BR2_ARCH_HAS_ATOMICS.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
pulseaudio is able to either use the atomic __sync builtins from the
compiler, or to rely on libatomic_ops for atomic operations. However,
since it anyway selects json-c which requires the __sync built-ins, it
means using libatomic_ops is useless: even if you use libatomic_ops
for pulseaudio, you'd still get a link error in pulseaudio due to the
missing __sync built-in for the json-c library.
Also, since pulseaudio now inherits the BR2_TOOLCHAIN_HAS_SYNC_4 from
json-c, which matches the __sync built-in from pulseaudio, this
commit:
- Drops the BR2_ARCH_HAS_ATOMICS dependency
- Forces pulseaudio to not detect libatomic_ops
- Propagates the removal of BR2_ARCH_HAS_ATOMICS dependency to
pulseaudio's reverse dependencies.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
While json-c itself builds fine on platforms that don't provide the
__sync atomic built-ins, it does use them. json-c doesn't fail to
build because only a library is built, so such function calls are left
unresolved. But as soon as it gets used in another package linked in a
program, linking will fail due to the missing
__sync_val_compare_and_swap_4() function.
To fix this, we make json-c depend on BR2_TOOLCHAIN_HAS_SYNC_4, and
propagate to the reverse dependencies:
docs/manual: document usage of BR2_TOOLCHAIN_HAS_SYNC_x
This commit updates the documentation to detail when and how to use
the BR2_TOOLCHAIN_HAS_SYNC_x dependency. Note that we chose to not add
a comment about this dependency, because it is mainly tied to
architecture capabilities (except in very specific cases, which would
be way too complicated to explain in a Config.in comment).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, Buildroot provides one BR2_ARCH_HAS_ATOMICS boolean option
to indicate whether the architecture supports atomic operations or
not. However, the reality of atomic operations support is much more
complicated and requires more than one option to be expressed
properly.
There are in fact two types of atomic built-ins provided by gcc:
(1) The __sync_*() family of functions, which have been in gcc for a
long time (probably gcc 4.1). They are available in variants
operating on 1-byte, 2-byte, 4-byte and 8-byte integers. Some
architectures implement a number of variants, some do not
implement any, some implement all of them.
They are now considered "legacy" by the gcc developers but are
nonetheless still being used by a significant number of userspace
libraries and applications.
(2) The __atomic_*() family of functions, which have been introduced
in gcc 4.7. They have been introduced in order to support C++11
atomic operations. In gcc 4.8, they are available on all
architectures, either built-in or in the libatomic library part
of the gcc runtime (in which case the application needs to be
linked with -latomic). In gcc 4.7, the __atomic_*() intrinsics
are only supported on certain architectures, since libatomic did
not exist at the time.
For (1), a single BR2_ARCH_HAS_ATOMICS is not sufficient, because
depending on the architecture, some variants may or may not be
available. Setting BR2_ARCH_HAS_ATOMICS to false as soon as one of the
variant is missing would cause a large number of packages to become
unavailable, even if they in fact use only more common variants
available on a large number of architectures. For this reason, we've
chosen to introduce four new Config.in options:
Which indicate whether the toolchain support 1-byte, 2-byte, 4-byte
and 8-byte __sync_*() built-ins respectively.
For (2), we introduce a BR2_TOOLCHAIN_HAS_ATOMIC, which indicates if
the __atomic_*() built-ins are available. Note that it is up to the
package to link with -latomic when gcc is >= 4.8. Since __atomic_*()
intrinsics for all sizes are supported starting
We conducted a fairly large analysis about various architectures
supported by Buildroot, as well as with a number of different
toolchains, to check which combinations support which variant. To do,
we linked the following program with various toolchains:
And looked at which symbols were unresolved. For the __atomic_*()
ones, we tested with and without -latomic to see which variants are
built-in, which variants require libatomic. This testing effort has
led to the following results:
__sync __atomic gcc
1 2 4 8 1 2 4 8
ARC Y Y Y - Y Y Y L 4.8 [with BR2_ARC_ATOMIC_EXT]
ARC - - - - L L L L 4.8 [without BR2_ARC_ATOMIC_EXT]
ARM Y Y Y X Y Y Y Y 4.8, 4.7
ARM Y Y Y - 4.5
AArch64 Y Y Y Y Y Y Y Y 4.9, 5.1
Bfin - - Y - 4.3
i386 (i386) - - - - L L L L 4.9
i386 (i486..) Y Y Y - L L L L 4.9 [i486, c3, winchip2, winchip-c6]
i386 (> i586) Y Y Y Y L L L L 4.9
Microblaze - - Y - L L Y L 4.9
MIPS Y Y Y - Y Y Y L 4.9
MIPS64 Y Y Y Y Y Y Y Y 4.9
NIOS 2 Y Y Y - Y Y Y L 4.9, 5.2
PowerPC Y Y Y - Y Y Y L 4.9
SuperH Y Y Y - Y Y Y L 4.9
SPARC - - - - L L L L 4.9
SPARC64 Y Y Y Y Y Y Y Y 4.9
x86_64 Y Y Y Y Y Y Y Y 4.7, 4.9
Xtensa Y Y Y - Y Y Y Y 4.9
Notes:
* __atomic built-ins appeared in gcc 4.7, so for toolchais older than
that, the __atomic column is empty.
* Y means 'supported built-in'
* L means 'supported via linking to libatomic' (only for __atomic
functions)
* X indicates a very special case for 8 bytes __sync built-ins on
ARM. On ARMv7, there is no problem, starting from gcc 4.7, the
__sync built-in for 8 bytes integers is implemented, fully in
userspace. For cores < ARMv7, doing a 8 bytes atomic operation
requires help from the kernel. Unfortunately, the libgcc code
implementing this uses the __write() function to display an error,
and this function is internal to glibc. Therefore, if you're using
glibc everything is fine, but if you're using uClibc or musl, you
cannot link an application that uses 8 bytes __sync
operations. This has been fixed as part of gcc PR68095, merged in
the gcc 5 branch but not yet part of any gcc release.
* - means not supported
This commit only introduces the new options. Follow-up commits will
progressively change the packages using BR2_ARCH_HAS_ATOMICS to use
the appropriate BR2_TOOLCHAIN_HAS_SYNC_x or BR2_TOOLCHAIN_HAS_ATOMIC
until the point where BR2_ARCH_HAS_ATOMICS can be removed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Yann E. MORIN [Fri, 5 Feb 2016 23:06:18 +0000 (00:06 +0100)]
defconfigs: all use the headers from the kernel
For most defconfigs, it was trivial to deduce the kernel version, by
just reading the version string, which could be:
- a standard upstream version string vX.Y.Z
- a non-standard version string, but still containg the standard X.Y.Z
Those for which it was not so trivial were those hosted on git tree.
Since most were already using a custom linux-headers version, it could
be easily deduced from that. It was confirmed by browsing said git trees
and check the version there.
There are a few cases were there was a mismatch:
- microzed: uses a 3.18 kernel, but 3.8 headers; fixed.
- xilinx_zc706: uses a 3.14 kernel, but 3.8 headers; fixed.
- zedboard: uses a 3.18 kernel, but 3.8 headers; fixed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Yann E. MORIN [Fri, 5 Feb 2016 23:06:16 +0000 (00:06 +0100)]
defconfigs: use the new headers-version-same-as-kernel-version option
Now that we can say that the linux headers version should match that of
the kernel to be built, we inverse the logic in our defconfigs, as it is
more sensible that way.
And also because we'll get rid of the former, converse kernel-same-as-headers
option.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Jan Heylen [Sat, 6 Feb 2016 09:00:07 +0000 (10:00 +0100)]
bind: fix intermittent build issues with high BR2_JLEVEL
Build sometimes breaks with:
libtool: link: `unix/os.lo' is not a valid libtool object
make[3]: *** [rndc-confgen] Error 1
make[3]: *** Waiting for unfinished jobs....
make[4]: Leaving directory `/scratch/peko/build/bind-9.6-ESV-R4/bin/rndc/unix'
So disable parallel builds.
This patch was removed with commit c36b5d89c5616f7ca0a7295cbb5c231606beb71e by Gustavo Zacarias
<gustavo@zacarias.com.ar> but the problem still occurs, so disabling
parallel builds again.
Carlos Santos [Thu, 4 Feb 2016 15:26:03 +0000 (13:26 -0200)]
libbsd: upgrade to v0.8.2 and expand architecture support
When libbsd still supported uClibc as a C library, we added the architecture
exclusions because uClibc's a.out.h includes linux/a.out.h. The latter only
exists for the specified architectures.
However, glibc doesn't include linux/a.out.h, it instead has its own
implementation and it adds a flag to indicate if a.out is supported on this
architecture or not.
Since libbsd currently only supports glibc-based toolchains, the architecture
exclusions are no longer valid.
On microblaze, the build still fails, but this time because of ELF support.
libbsd explicitly handles architectures and microblaze is not one of them (see
local-elf.h).
Signed-off-by: Carlos Santos <casantos@datacom.ind.br> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bernd Kuhls [Fri, 5 Feb 2016 21:18:25 +0000 (22:18 +0100)]
package/rsyslog: fix musl buil
The build error was not yet being found by the autobuilders:
omfile.c: In function ‘prepareFile’:
omfile.c:580:3: error: implicit declaration of function ‘open’ [-Werror=implicit-function-declaration]
fd = open((char*) newFileName, O_WRONLY|O_APPEND|O_CREAT|O_NOCTTY|O_CLOEXEC,
^
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Lada Trimasova [Fri, 5 Feb 2016 12:46:40 +0000 (15:46 +0300)]
toolchain: bump ARC toolchain components to arc-2015.12
This change introduces newer ARC toolchain in Buildroot.
That new arc-2015.12 release doesn't bring any significant changes
but mostly is focused on fixes and minor improvements here and there.
Most noticeable changes are:
* GCC: Source update to v4.8.5
* GDB: Updated to upstream 7.10 release.
You may find more info on fixes and improvements in that release at:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2015.12
Signed-off-by: Lada Trimasova <ltrimas@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The architecture dependencies of protobuf are going to change, and
they are already duplicated between protobuf, ola and mosh. In order
to factorize the expression of those dependencies, this commit
introduces BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS.
Note that we include in this hidden Config.in option both the target
architecture dependency and the host architecture dependency.
Finally, this commit also fixes a real mistake in the mosh Config.in
file, where the condition on the architecture dependency for the
Config.in comment was inverted: we only want to show the Config.in
comment when we are on supported architectures.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
projects / coffee / buildroot.git / log