Rework atomic handling
v2 cover Rework atomic handling
Hello,
As many of you are aware, we have a number of build failures related to __sync_*() atomic operations, which we can't really solve properly today with our single BR2_ARCH_HAS_ATOMICS boolean option.
This patch series aims at reworking our atomic operation handling, by introducing four options: BR2_TOOLCHAIN_HAS_SYNC_1, BR2_TOOLCHAIN_HAS_SYNC_2, BR2_TOOLCHAIN_HAS_SYNC_4, BR2_TOOLCHAIN_HAS_SYNC_8, to indicate which variants of atomic operations are available, depending on the architecture/toolchain. The full details are explained in PATCH 1.
The overall direction of the series is:
- PATCH 1 introduces the BR2_TOOLCHAIN_HAS_SYNC_x options, and has all the explanations about why we're doing this.
- PATCH 2 updates the manual about the BR2_TOOLCHAIN_HAS_SYNC_x options.
- PATCH 3-12 aim at replacing the BR2_ARCH_HAS_ATOMICS usage by the appropriate BR2_TOOLCHAIN_HAS_SYNC_x options. Note that in some cases, BR2_ARCH_HAS_ATOMICS can be removed completely.
Along the way, we found that json-c was using some __sync_*() built-ins, so we added this dependency, which fixes some build failure.
- PATCH 13 removes the BR2_ARCH_HAS_ATOMICS option, which has become no longer used.
- PATCH 14-17 use the new BR2_TOOLCHAIN_HAS_SYNC_x options to fix numerous outstanding build failures related to atomic operations.
Changes compared to v1:
- Drop patches that have been merged:
libftdi: C++ bindings need boost
libftdi: remove BR2_ARCH_HAS_ATOMICS dependency
icu: remove BR2_ARCH_HAS_ATOMICS dependency
openocd: remove BR2_ARCH_HAS_ATOMICS dependency
- Fix numerous english typos in the commit log of "toolchain: add BR2_TOOLCHAIN_HAS_SYNC_x hidden booleans" as well as in the patch itself. Following the review from Yann E. Morin.
- Introduced a BR2_TOOLCHAIN_X86_HAS_SYNC_8 in "toolchain: add BR2_TOOLCHAIN_HAS_SYNC_x hidden booleans" to simplify the expression of the availability of 8-byte intrinsics on 32 bits x86. Suggested by Yann E. Morin.
- In the documentation patch, remove a stray paragraph from a previous write-up documenting the new BR2_TOOLCHAIN_HAS_SYNC_x options. Noticed by Yann E. Morin.
- Fix minor typo and add Reviewed-by from Yann E. Morin on patch "json-c: needs __sync_val_compare_and_swap_4".
- Explicitly pass --disable-nonportable-atomics to the apr package configure script when no appropriate atomic __sync functions are available. Suggested by Yann E. Morin.
- Added Reviewed-by: "Yann E. MORIN" <[email protected]> on:
jack2: use the proper BR2_TOOLCHAIN_HAS_SYNC_x symbol
gauche: disable on SPARC(64), remove atomics dependency
msgpack: rework BR2_ARCH_HAS_ATOMICS dependency
- Added Tested-by/Acked from Yann E. Morin on:
libtorrent: use the proper BR2_TOOLCHAIN_HAS_SYNC_x symbols
thrift: remove BR2_ARCH_HAS_ATOMICS dependency
- Added Acked-by: "Yann E. MORIN" <[email protected]> on
squid: rework atomic handling
arch: remove BR2_ARCH_HAS_ATOMICS option
neard: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
freerdp: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
openal: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
- Fix a few typos in the commit log of "glog: fix atomic built-in problem" and added Reviewed-by from Yann E. Morin.
Those interested can also find this series in the Git branch at:
http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=atomic-rework
Thanks in advance for your review and comments!
Thomas
Thomas Petazzoni (17):
toolchain: add BR2_TOOLCHAIN_HAS_SYNC_x hidden booleans docs/manual: document usage of BR2_TOOLCHAIN_HAS_SYNC_x
json-c: needs __sync_val_compare_and_swap_4
pulseaudio: remove BR2_ARCH_HAS_ATOMICS dependency apache, apr: fix atomic handling
jack2: use the proper BR2_TOOLCHAIN_HAS_SYNC_x symbol
libtorrent: use the proper BR2_TOOLCHAIN_HAS_SYNC_x symbols
gauche: disable on SPARC(64), remove atomics dependency cairo, harfbuzz: rework atomic dependencies
squid: rework atomic handling
thrift: remove BR2_ARCH_HAS_ATOMICS dependency
msgpack: rework BR2_ARCH_HAS_ATOMICS dependency
arch: remove BR2_ARCH_HAS_ATOMICS option
glog: fix atomic built-in problem
openal: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
freerdp: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
neard: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
arch/Config.in | 4 -- arch/Config.in.aarch64 | 3 -- arch/Config.in.arc | 3 -- arch/Config.in.arm | 3 -- arch/Config.in.bfin | 3 -- arch/Config.in.m68k | 3 -- arch/Config.in.microblaze | 3 -- arch/Config.in.mips | 3 -- arch/Config.in.nios2 | 3 -- arch/Config.in.powerpc | 3 -- arch/Config.in.sh | 3 -- arch/Config.in.x86 | 3 -- arch/Config.in.xtensa | 3 -- docs/manual/adding-packages-directory.txt | 11 +++-- package/apache/apache.mk | 4 -- package/apr/apr.mk | 15 ++++++ package/cairo/Config.in | 1 - package/cairo/cairo.mk | 6 +++ package/cairomm/Config.in | 2 - package/connman/Config.in | 1 + package/cwiid/Config.in | 2 +- package/directfb/Config.in | 5 +- package/efl/Config.in | 2 +- package/enlightenment/Config.in | 6 +-- package/espeak/Config.in | 2 +- package/fastd/Config.in | 1 + package/freerdp/Config.in | 2 + package/gauche/Config.in | 5 +- package/glog/glog.mk | 11 +++++ package/gstreamer/gst-plugins-bad/Config.in | 4 +- package/gstreamer/gst-plugins-base/Config.in | 4 +- package/gstreamer/gst-plugins-good/Config.in | 5 +- package/gstreamer1/gst1-plugins-bad/Config.in | 6 ++- package/gstreamer1/gst1-plugins-base/Config.in | 4 +- package/gstreamer1/gst1-plugins-good/Config.in | 5 +- package/gtkmm3/Config.in | 4 +- package/harfbuzz/Config.in | 2 + package/jack2/Config.in | 4 +- package/json-c/Config.in | 2 + package/libevas-generic-loaders/Config.in | 4 +- package/libfm/Config.in | 4 +- package/libgail/Config.in | 4 +- package/libgdiplus/Config.in | 2 - package/libgtk2/Config.in | 4 +- package/libgtk3/Config.in | 4 +- package/librsvg/Config.in | 4 +- package/libsvg-cairo/Config.in | 1 - package/libtorrent/Config.in | 4 +- package/mpd/Config.in | 6 ++- package/msgpack/Config.in | 4 +- package/neard/Config.in | 2 + package/openal/Config.in | 2 + package/openbox/Config.in | 4 +- package/opencv/Config.in | 2 +- package/opencv3/Config.in | 4 +- package/pango/Config.in | 4 +- package/pangomm/Config.in | 4 +- package/pcmanfm/Config.in | 4 +- package/pinentry/Config.in | 4 +- package/pulseaudio/Config.in | 4 +- package/pulseaudio/pulseaudio.mk | 7 ++- package/python-msgpack/Config.in | 4 +- package/rrdtool/Config.in | 2 +- package/rsyslog/Config.in | 2 + package/rtorrent/Config.in | 4 +- package/squid/squid.mk | 10 ++-- package/thrift/Config.in | 2 - package/ubus/Config.in | 1 + package/webkit/Config.in | 4 +- package/webkitgtk24/Config.in | 4 +- package/weston/Config.in | 4 +- package/xscreensaver/Config.in | 4 +- toolchain/toolchain-common.in | 65 ++++++++++++++++++++++++++ 73 files changed, 205 insertions(+), 139 deletions(-)
Signature · 1 line
2.6.4
PATCH v2 1/17 toolchain: add BR2_TOOLCHAIN_HAS_SYNC_x hidden booleans
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, certain do not implement any, certain architectures 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.
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html
(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. 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).
Since (2) are available on all architectures starting gcc 4.7, we do not need to add any new option for them: packages using them should depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 and link with libatomic.
However, 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:
- BR2_TOOLCHAIN_HAS_SYNC_1
- BR2_TOOLCHAIN_HAS_SYNC_2
- BR2_TOOLCHAIN_HAS_SYNC_3
- BR2_TOOLCHAIN_HAS_SYNC_4
Which indicate whether the toolchain support 1-byte, 2-byte, 4-byte and 8-byte __sync_*() built-ins respectively.
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:
int main(void)
{
uint8_t a;
uint16_t b;
uint32_t c;
uint64_t d;
__sync_fetch_and_add(&a, 3);
__sync_fetch_and_add(&b, 3);
__sync_fetch_and_add(&c, 3);
__sync_fetch_and_add(&d, 3);
__sync_val_compare_and_swap(&a, 1, 2);
__sync_val_compare_and_swap(&b, 1, 2);
__sync_val_compare_and_swap(&c, 1, 2);
__sync_val_compare_and_swap(&d, 1, 2);
__atomic_add_fetch(&a, 3, __ATOMIC_RELAXED);
__atomic_add_fetch(&b, 3, __ATOMIC_RELAXED);
__atomic_add_fetch(&c, 3, __ATOMIC_RELAXED);
__atomic_add_fetch(&d, 3, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&a, &a, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&b, &b, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&c, &c, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&d, &d, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
return 0;
}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.9Notes:
* __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
As said above:
* For the __atomic_*() built-ins, we do not add any new Config.in option, since they are all available on all architectures as long as you link with libatomic and depend on gcc >= 4.7.
* For the __sync_*() built-ins, we add one option for each size, encoding on which architectures they are available or not. There is only one case where the gcc version/C library comes into play: on ARM, where the situation is a bit complicated for 8 bytes atomics.
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, until the point where BR2_ARCH_HAS_ATOMICS can be removed.
--- toolchain/toolchain-common.in | 65 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+)
toolchain/toolchain-common.in +65 -0
@@ -313,3 +313,68 @@ config BR2_TOOLCHAIN_GCC_AT_LEAST default "4.5" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_5 default "4.4" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_4 default "4.3" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_3 + +config BR2_TOOLCHAIN_HAS_SYNC_1 + bool + default y + depends on !BR2_x86_i386 + depends on !BR2_bfin + depends on !BR2_microblaze + depends on !BR2_sparc + depends on !(BR2_arc && !BR2_ARC_ATOMIC_EXT) + +config BR2_TOOLCHAIN_HAS_SYNC_2 + bool + default y if BR2_TOOLCHAIN_HAS_SYNC_1 + +config BR2_TOOLCHAIN_HAS_SYNC_4 + bool + default y + depends on !BR2_sparc + depends on !BR2_x86_i386 + depends on !(BR2_arc && !BR2_ARC_ATOMIC_EXT) + +# The availability of __sync for 8-byte types on ARM is somewhat +# complicated: +# +# - It appeared in gcc starting with gcc 4.7. +# +# - On ARMv7, there is no problem, it can be directly implemented in +# userspace. +# +# - On < ARMv7, it requires help from the kernel. Unfortunately, the +# libgcc code implementing 8-byte __sync with the help from the +# kernel calls __write() when a failure occurs, which is a function +# internal to glibc, not available in uClibc and musl. This means +# that the 8-byte __sync operations are not available on < ARMv7 +# with uClibc and musl. This problem was fixed as part of gcc +# PR68059, which was backported to the gcc 5 branch, but isn't yet +# part of any gcc 5.x release. +# +config BR2_TOOLCHAIN_ARM_HAS_SYNC_8 + bool + default y + depends on BR2_arm || BR2_armeb + depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 + depends on BR2_TOOLCHAIN_USES_GLIBC || BR2_ARM_CPU_ARMV7A + +# 8-byte intrinsics available on most x86 CPUs, except a few old ones +config BR2_TOOLCHAIN_X86_HAS_SYNC_8 + bool + default y + depends on BR2_i386 + depends on !BR2_x86_i386 + depends on !BR2_x86_i486 + depends on !BR2_x86_c3 + depends on !BR2_x86_winchip_c6 + depends on !BR2_x86_winchip2 + +# 8-byte intrinsics available: +# - On all 64 bits architecture +# - On a certain combinations of ARM platforms +# - On certain x86 32 bits CPUs +config BR2_TOOLCHAIN_HAS_SYNC_8 + bool + default y if BR2_ARCH_IS_64 + default y if BR2_TOOLCHAIN_ARM_HAS_SYNC_8 + default y if BR2_TOOLCHAIN_X86_HAS_SYNC_8
Signature · 1 line
2.6.4
PATCH v2 1/17 toolchain: add BR2_TOOLCHAIN_HAS_SYNC_x hidden booleans
Thomas, All,
On 2016-01-27 23:47 +0100, Thomas Petazzoni spake thusly:
Quoted 6 lines
Currently, Buildroot provides one
BR2_ARCH_HAS_ATOMICSboolean 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.
Quoted 6 lines
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, certain do not
s/certain/some/
Quoted 1 line
implement any, certain architectures implement all of them.
s/certain architectures/some/ (indeed, no need to repeat 'architecture' here, it's implicit here.)
[--SNIP--]
Quoted 1 line
Signed-off-by Thomas Petazzoni <[email protected]>
With the above fixed:
Regards,
Yann E. MORIN.
Quoted 84 lines
--- toolchain/toolchain-common.in | 65 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+)toolchain/toolchain-common.in +65
-0@@ -313,3 +313,68 @@ config BR2_TOOLCHAIN_GCC_AT_LEAST default "4.5" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_5 default "4.4" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_4 default "4.3" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_3 + +config BR2_TOOLCHAIN_HAS_SYNC_1 + bool + default y + depends on !BR2_x86_i386 + depends on !BR2_bfin + depends on !BR2_microblaze + depends on !BR2_sparc + depends on !(BR2_arc && !BR2_ARC_ATOMIC_EXT) + +config BR2_TOOLCHAIN_HAS_SYNC_2 + bool + default y if BR2_TOOLCHAIN_HAS_SYNC_1 + +config BR2_TOOLCHAIN_HAS_SYNC_4 + bool + default y + depends on !BR2_sparc + depends on !BR2_x86_i386 + depends on !(BR2_arc && !BR2_ARC_ATOMIC_EXT) + +# The availability of __sync for 8-byte types on ARM is somewhat +# complicated: +# +# - It appeared in gcc starting with gcc 4.7. +# +# - On ARMv7, there is no problem, it can be directly implemented in +# userspace. +# +# - On < ARMv7, it requires help from the kernel. Unfortunately, the +# libgcc code implementing 8-byte __sync with the help from the +# kernel calls __write() when a failure occurs, which is a function +# internal to glibc, not available in uClibc and musl. This means +# that the 8-byte __sync operations are not available on < ARMv7 +# with uClibc and musl. This problem was fixed as part of gcc +# PR68059, which was backported to the gcc 5 branch, but isn't yet +# part of any gcc 5.x release. +# +config BR2_TOOLCHAIN_ARM_HAS_SYNC_8 + bool + default y + depends on BR2_arm || BR2_armeb + depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_7 + depends on BR2_TOOLCHAIN_USES_GLIBC || BR2_ARM_CPU_ARMV7A + +# 8-byte intrinsics available on most x86 CPUs, except a few old ones +config BR2_TOOLCHAIN_X86_HAS_SYNC_8 + bool + default y + depends on BR2_i386 + depends on !BR2_x86_i386 + depends on !BR2_x86_i486 + depends on !BR2_x86_c3 + depends on !BR2_x86_winchip_c6 + depends on !BR2_x86_winchip2 + +# 8-byte intrinsics available: +# - On all 64 bits architecture +# - On a certain combinations of ARM platforms +# - On certain x86 32 bits CPUs +config BR2_TOOLCHAIN_HAS_SYNC_8 + bool + default y if BR2_ARCH_IS_64 + default y if BR2_TOOLCHAIN_ARM_HAS_SYNC_8 + default y if BR2_TOOLCHAIN_X86_HAS_SYNC_8Signature · 6 lines
2.6.4 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v2 2/17 docs/manual: document usage of BR2_TOOLCHAIN_HAS_SYNC_x
In reply to Thomas PetazzoniThis 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).
--- docs/manual/adding-packages-directory.txt | 10 ++++++++++ 1 file changed, 10 insertions(+)
docs/manual/adding-packages-directory.txt +10 -0
@@ -279,6 +279,16 @@ use in the comment. ** Dependency symbol: +BR2_ARCH_HAS_ATOMICS+ ** Comment string: no comment to be added +* Gcc +__sync_*+ built-ins used for atomic operations. They are + available in variants operating on 1 byte, 2 bytes, 4 bytes and 8 + bytes. Since different architectures support atomic operations on + different sizes, one dependency symbol is available for each size: +** Dependency symbol: +BR2_TOOLCHAIN_HAS_SYNC_1+ for 1 byte, + +BR2_TOOLCHAIN_HAS_SYNC_2+ for two bytes, + +BR2_TOOLCHAIN_HAS_SYNC_4+ for 4 bytes, +BR2_TOOLCHAIN_HAS_SYNC_8+ + for 8 bytes. +** Comment string: no comment to be added + * Kernel headers ** Dependency symbol: +BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y+, (replace +X_Y+ with the proper version, see +toolchain/toolchain-common.in+)
Signature · 1 line
2.6.4
PATCH v2 2/17 docs/manual: document usage of BR2_TOOLCHAIN_HAS_SYNC_x
Thomas, All,
On 2016-01-27 23:47 +0100, Thomas Petazzoni spake thusly:
Quoted 16 lines
This commit updates the documentation to detail when and how to use the
BR2_TOOLCHAIN_HAS_SYNC_xdependency. 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 <[email protected]>--- docs/manual/adding-packages-directory.txt | 10 ++++++++++ 1 file changed, 10 insertions(+)docs/manual/adding-packages-directory.txt +0
-0
docs/manual/adding-packages-directory.txt use in the comment. · line 287
Quoted 9 lines
docs/manual/adding-packages-directory.txt +6
-0@@ -279,6 +279,16 @@ use in the comment. ** Dependency symbol: +BR2_ARCH_HAS_ATOMICS+ ** Comment string: no comment to be added +* Gcc +__sync_*+ built-ins used for atomic operations. They are + available in variants operating on 1 byte, 2 bytes, 4 bytes and 8 + bytes. Since different architectures support atomic operations on + different sizes, one dependency symbol is available for each size: +** Dependency symbol: +BR2_TOOLCHAIN_HAS_SYNC_1+ for 1 byte, + +BR2_TOOLCHAIN_HAS_SYNC_2+ for two bytes,
Why 'two' in letters here, when you otherwise have 1, 4 and 8 in numerals?
Otherwise:
Regards,
Yann E. MORIN.
Quoted 14 lines
docs/manual/adding-packages-directory.txt +4
-0+ +BR2_TOOLCHAIN_HAS_SYNC_4+ for 4 bytes, +BR2_TOOLCHAIN_HAS_SYNC_8+ + for 8 bytes. +** Comment string: no comment to be added + * Kernel headers ** Dependency symbol: +BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y+, (replace +X_Y+ with the proper version, see +toolchain/toolchain-common.in+)Signature · 6 lines
2.6.4 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v2 3/17 json-c: needs __sync_val_compare_and_swap_4
In reply to Thomas PetazzoniWhile 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:
- json-c
- fastd
- pulseaudio
- efl
- espeak
- gst-plugins-good
- gst1-plugins-good
- mpd
- rsyslog
- ubus
Note that pulseaudio already had a BR2_ARCH_HAS_ATOMICS dependency, which we are keeping for the moment, and will clean-up in a subsequent commit.
This commit will also fix packages that could optionally use json-c, and therefore fixes build failures like:
http://autobuild.buildroot.org/results/4fe/4feaa9089ee9a183c5086b791bea35c0156945af/
--- package/efl/Config.in | 1 + package/espeak/Config.in | 1 + package/fastd/Config.in | 1 + package/gstreamer/gst-plugins-good/Config.in | 1 + package/gstreamer1/gst1-plugins-good/Config.in | 1 + package/json-c/Config.in | 2 ++ package/mpd/Config.in | 1 + package/pulseaudio/Config.in | 2 ++ package/rsyslog/Config.in | 2 ++ package/ubus/Config.in | 1 + 10 files changed, 13 insertions(+)
package/efl/Config.in +1 -0
@@ -82,6 +82,7 @@ config BR2_PACKAGE_EFL_LIBSNDFILE config BR2_PACKAGE_EFL_PULSEAUDIO bool "Enable pulseaudio support (recommended)" depends on BR2_ARCH_HAS_ATOMICS # pulseaudio + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO default y help
package/espeak/Config.in +1 -0
@@ -33,6 +33,7 @@ config BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_ALSA config BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_PULSEAUDIO bool "pulseaudio" depends on BR2_ARCH_HAS_ATOMICS # pulseaudio + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO endchoice
package/fastd/Config.in +1 -0
@@ -18,6 +18,7 @@ config BR2_PACKAGE_FASTD_STATUS_SOCKET bool "status socket support" default y select BR2_PACKAGE_JSON_C + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # json-c help Enable support for a socket to get fastd's status.
package/gstreamer/gst-plugins-good/Config.in +1 -0
@@ -206,6 +206,7 @@ config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_PULSE depends on BR2_USE_MMU # pulseaudio depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on !BR2_STATIC_LIBS # pulseaudio + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO bool "pulseaudio"
package/gstreamer1/gst1-plugins-good/Config.in +1 -0
@@ -313,6 +313,7 @@ config BR2_PACKAGE_GST1_PLUGINS_GOOD_PLUGIN_PULSE depends on BR2_USE_MMU # pulseaudio depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on !BR2_STATIC_LIBS # pulseaudio + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO bool "pulseaudio" help
package/json-c/Config.in +2 -0
@@ -1,5 +1,7 @@ config BR2_PACKAGE_JSON_C bool "json-c" + # uses __sync_val_compare_and_swap_4 + depends on BR2_TOOLCHAIN_HAS_SYNC_4 help JSON-C - A JSON implementation in C
package/mpd/Config.in +1 -0
@@ -248,6 +248,7 @@ config BR2_PACKAGE_MPD_PULSEAUDIO bool "pulseaudio" depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on !BR2_STATIC_LIBS # pulseaudio + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO help Enable pulseaudio output support.
package/pulseaudio/Config.in +2 -0
@@ -3,6 +3,7 @@ config BR2_PACKAGE_PULSEAUDIO depends on BR2_USE_WCHAR depends on BR2_TOOLCHAIN_HAS_THREADS depends on !BR2_STATIC_LIBS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # json-c select BR2_PACKAGE_LIBTOOL select BR2_PACKAGE_JSON_C select BR2_PACKAGE_LIBSNDFILE
@@ -34,4 +35,5 @@ endif comment "pulseaudio needs a toolchain w/ wchar, threads, dynamic library" depends on BR2_USE_MMU depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
package/rsyslog/Config.in +2 -0
@@ -7,6 +7,7 @@ config BR2_PACKAGE_RSYSLOG depends on BR2_TOOLCHAIN_HAS_THREADS depends on BR2_USE_MMU # fork() depends on !BR2_STATIC_LIBS # modules + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # json-c help Rsyslog is a powerful and flexible syslog implementation
@@ -14,4 +15,5 @@ config BR2_PACKAGE_RSYSLOG comment "rsyslog needs a toolchain w/ threads, dynamic library" depends on BR2_USE_MMU + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
package/ubus/Config.in +1 -0
@@ -5,6 +5,7 @@ config BR2_PACKAGE_UBUS bool "ubus" select BR2_PACKAGE_LIBUBOX select BR2_PACKAGE_JSON_C + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # json-c depends on !BR2_STATIC_LIBS # libubox help IPC/RPC bus that allows communication between processes.
Signature · 1 line
2.6.4
PATCH v2 3/17 json-c: needs __sync_val_compare_and_swap_4
Thomas, All,
On 2016-01-27 23:47 +0100, Thomas Petazzoni spake thusly:
Quoted 25 lines
While json-c itself builds fine on platforms that don't provide the
__syncatomic 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:- json-c
- fastd
- pulseaudio
- efl
- espeak
- gst-plugins-good
- gst1-plugins-good
- mpd
- rsyslog
- ubusNote that pulseaudio already had a
BR2_ARCH_HAS_ATOMICSdependency, which we are keeping for the moment, and will clean-up in a subsequent commit.
Quoted 7 lines
This commit will also fix packages that could optionally use json-c, and therefore fixes build failures like:
http://autobuild.buildroot.org/results/4fe/4feaa9089ee9a183c5086b791bea35c0156945af/
Signed-off-by Thomas Petazzoni <[email protected]>Reviewed-by "Yann E. MORIN" <[email protected]>
Except you'll have to propagate this new dependency on _SYNC_4 to the comments, rather than do it in the following patch, as we discussed in the previous review round.
Regards,
Yann E. MORIN.
Quoted 152 lines
--- package/efl/Config.in | 1 + package/espeak/Config.in | 1 + package/fastd/Config.in | 1 + package/gstreamer/gst-plugins-good/Config.in | 1 + package/gstreamer1/gst1-plugins-good/Config.in | 1 + package/json-c/Config.in | 2 ++ package/mpd/Config.in | 1 + package/pulseaudio/Config.in | 2 ++ package/rsyslog/Config.in | 2 ++ package/ubus/Config.in | 1 + 10 files changed, 13 insertions(+)package/efl/Config.in +1
-0@@ -82,6 +82,7 @@ config BR2_PACKAGE_EFL_LIBSNDFILE config BR2_PACKAGE_EFL_PULSEAUDIO bool "Enable pulseaudio support (recommended)" depends on BR2_ARCH_HAS_ATOMICS # pulseaudio + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO default y helppackage/espeak/Config.in +1
-0@@ -33,6 +33,7 @@ config BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_ALSA config BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_PULSEAUDIO bool "pulseaudio" depends on BR2_ARCH_HAS_ATOMICS # pulseaudio + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO endchoicepackage/fastd/Config.in +1
-0@@ -18,6 +18,7 @@ config BR2_PACKAGE_FASTD_STATUS_SOCKET bool "status socket support" default y select BR2_PACKAGE_JSON_C + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # json-c help Enable support for a socket to get fastd's status.package/gstreamer/gst-plugins-good/Config.in +1
-0@@ -206,6 +206,7 @@ config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_PULSE depends on BR2_USE_MMU # pulseaudio depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on !BR2_STATIC_LIBS # pulseaudio + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO bool "pulseaudio"package/gstreamer1/gst1-plugins-good/Config.in +1
-0@@ -313,6 +313,7 @@ config BR2_PACKAGE_GST1_PLUGINS_GOOD_PLUGIN_PULSE depends on BR2_USE_MMU # pulseaudio depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on !BR2_STATIC_LIBS # pulseaudio + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO bool "pulseaudio" helppackage/json-c/Config.in +2
-0@@ -1,5 +1,7 @@ config BR2_PACKAGE_JSON_C bool "json-c" + # uses __sync_val_compare_and_swap_4 + depends on BR2_TOOLCHAIN_HAS_SYNC_4 help JSON-C - A JSON implementation in Cpackage/mpd/Config.in +1
-0@@ -248,6 +248,7 @@ config BR2_PACKAGE_MPD_PULSEAUDIO bool "pulseaudio" depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on !BR2_STATIC_LIBS # pulseaudio + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO help Enable pulseaudio output support.package/pulseaudio/Config.in +2
-0@@ -3,6 +3,7 @@ config BR2_PACKAGE_PULSEAUDIO depends on BR2_USE_WCHAR depends on BR2_TOOLCHAIN_HAS_THREADS depends on !BR2_STATIC_LIBS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # json-c select BR2_PACKAGE_LIBTOOL select BR2_PACKAGE_JSON_C select BR2_PACKAGE_LIBSNDFILE@@ -34,4 +35,5 @@ endif comment "pulseaudio needs a toolchain w/ wchar, threads, dynamic library" depends on BR2_USE_MMU depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBSpackage/rsyslog/Config.in +2
-0@@ -7,6 +7,7 @@ config BR2_PACKAGE_RSYSLOG depends on BR2_TOOLCHAIN_HAS_THREADS depends on BR2_USE_MMU # fork() depends on !BR2_STATIC_LIBS # modules + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # json-c help Rsyslog is a powerful and flexible syslog implementation@@ -14,4 +15,5 @@ config BR2_PACKAGE_RSYSLOG comment "rsyslog needs a toolchain w/ threads, dynamic library" depends on BR2_USE_MMU + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBSpackage/ubus/Config.in +1
-0@@ -5,6 +5,7 @@ config BR2_PACKAGE_UBUS bool "ubus" select BR2_PACKAGE_LIBUBOX select BR2_PACKAGE_JSON_C + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # json-c depends on !BR2_STATIC_LIBS # libubox help IPC/RPC bus that allows communication between processes.Signature · 6 lines
2.6.4 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v2 4/17 pulseaudio: remove BR2_ARCH_HAS_ATOMICS dependency
In reply to Thomas Petazzonipulseaudio 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.
--- package/efl/Config.in | 1 - package/espeak/Config.in | 1 - package/gstreamer/gst-plugins-good/Config.in | 3 +-- package/gstreamer1/gst1-plugins-good/Config.in | 3 +-- package/mpd/Config.in | 2 +- package/pulseaudio/Config.in | 2 -- package/pulseaudio/pulseaudio.mk | 7 ++++++- 7 files changed, 9 insertions(+), 10 deletions(-)
package/efl/Config.in +0 -1
@@ -81,7 +81,6 @@ config BR2_PACKAGE_EFL_LIBSNDFILE config BR2_PACKAGE_EFL_PULSEAUDIO bool "Enable pulseaudio support (recommended)" - depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO default y
package/espeak/Config.in +0 -1
@@ -32,7 +32,6 @@ config BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_ALSA config BR2_PACKAGE_ESPEAK_AUDIO_BACKEND_PULSEAUDIO bool "pulseaudio" - depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO
package/gstreamer/gst-plugins-good/Config.in +1 -2
@@ -204,7 +204,6 @@ config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_OSS4 config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_PULSE depends on BR2_TOOLCHAIN_HAS_THREADS # pulseaudio depends on BR2_USE_MMU # pulseaudio - depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on !BR2_STATIC_LIBS # pulseaudio depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO
@@ -212,7 +211,7 @@ config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_PULSE comment "pulseaudio support needs a toolchain w/ threads, dynamic library" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_SOUPHTTPSRC
package/gstreamer1/gst1-plugins-good/Config.in +1 -2
@@ -311,7 +311,6 @@ comment "gdkpixbuf needs a toolchain w/ wchar, threads" config BR2_PACKAGE_GST1_PLUGINS_GOOD_PLUGIN_PULSE depends on BR2_TOOLCHAIN_HAS_THREADS # pulseaudio depends on BR2_USE_MMU # pulseaudio - depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on !BR2_STATIC_LIBS # pulseaudio depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO
@@ -321,7 +320,7 @@ config BR2_PACKAGE_GST1_PLUGINS_GOOD_PLUGIN_PULSE comment "pulseaudio support needs a toolchain w/ threads, dynamic library" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS config BR2_PACKAGE_GST1_PLUGINS_GOOD_PLUGIN_SOUPHTTPSRC
package/mpd/Config.in +1 -1
@@ -246,7 +246,6 @@ config BR2_PACKAGE_MPD_OSS config BR2_PACKAGE_MPD_PULSEAUDIO bool "pulseaudio" - depends on BR2_ARCH_HAS_ATOMICS # pulseaudio depends on !BR2_STATIC_LIBS # pulseaudio depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pulseaudio -> json-c select BR2_PACKAGE_PULSEAUDIO
@@ -254,6 +253,7 @@ config BR2_PACKAGE_MPD_PULSEAUDIO Enable pulseaudio output support. comment "pulseaudio support needs a toolchain w/ dynamic library" + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on BR2_STATIC_LIBS comment "Miscellaneous plugins"
package/pulseaudio/Config.in +0 -2
@@ -9,7 +9,6 @@ config BR2_PACKAGE_PULSEAUDIO select BR2_PACKAGE_LIBSNDFILE select BR2_PACKAGE_SPEEX depends on BR2_USE_MMU # fork() - depends on BR2_ARCH_HAS_ATOMICS help PulseAudio is a sound system for POSIX OSes, meaning that it is a proxy for your sound applications. It allows you to do
@@ -34,6 +33,5 @@ endif comment "pulseaudio needs a toolchain w/ wchar, threads, dynamic library" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
package/pulseaudio/pulseaudio.mk +6 -1
@@ -15,9 +15,14 @@ PULSEAUDIO_CONF_OPTS = \ --disable-legacy-database-entry-format \ --disable-manpages +# Make sure we don't detect libatomic_ops. Indeed, since pulseaudio +# requires json-c, which needs 4 bytes __sync builtins, there should +# be no need for pulseaudio to rely on libatomic_ops. +PULSE_AUDIO_CONF_ENV += \ + ac_cv_header_atomic_ops_h=no + PULSEAUDIO_DEPENDENCIES = \ host-pkgconf libtool json-c libsndfile speex host-intltool \ - $(if $(BR2_PACKAGE_LIBATOMIC_OPS),libatomic_ops) \ $(if $(BR2_PACKAGE_LIBSAMPLERATE),libsamplerate) \ $(if $(BR2_PACKAGE_ALSA_LIB),alsa-lib) \ $(if $(BR2_PACKAGE_LIBGLIB2),libglib2) \
Signature · 1 line
2.6.4
PATCH v2 4/17 pulseaudio: remove BR2_ARCH_HAS_ATOMICS dependency
Thomas, All,
On 2016-01-27 23:47 +0100, Thomas Petazzoni spake thusly:
Quoted 11 lines
pulseaudio is able to either use the atomic
__syncbuiltins from the compiler, or to rely onlibatomic_opsfor atomic operations. However, since it anyway selects json-c which requires the__syncbuilt-ins, it means usinglibatomic_opsis useless: even if you uselibatomic_opsfor pulseaudio, you'd still get a link error in pulseaudio due to the missing__syncbuilt-in for the json-c library.Also, since pulseaudio now inherits the
BR2_TOOLCHAIN_HAS_SYNC_4from json-c, which matches the__syncbuilt-in from pulseaudio, this commit:
Quoted 6 lines
- Drops the
BR2_ARCH_HAS_ATOMICSdependency
- Forces pulseaudio to not detectlibatomic_ops
- Propagates the removal ofBR2_ARCH_HAS_ATOMICSdependency to pulseaudio's reverse dependencies.Signed-off-by Thomas Petazzoni <[email protected]>
[--SNIP--]
package/gstreamer/gst-plugins-good/Config.in config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_PULSE · line 214
Quoted 10 lines
package/gstreamer/gst-plugins-good/Config.in +1
-1@@ -212,7 +211,7 @@ config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_PULSE comment "pulseaudio support needs a toolchain w/ threads, dynamic library" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4
EWhen you move the 'depends on _SYNC_4' to the previous patch (ditto for the other comments), you can add my:
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v2 5/17 apache, apr: fix atomic handling
In reply to Thomas PetazzoniSince 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.
--- package/apache/apache.mk | 4 ---- package/apr/apr.mk | 15 +++++++++++++++ 2 files changed, 15 insertions(+), 4 deletions(-)
package/apache/apache.mk +0 -4
@@ -35,10 +35,6 @@ APACHE_CONF_OPTS = \ --disable-lua \ --disable-luajit -ifeq ($(BR2_ARCH_HAS_ATOMICS),y) -APACHE_CONF_OPTS += --enable-nonportable-atomics=yes -endif - ifeq ($(BR2_PACKAGE_LIBXML2),y) APACHE_DEPENDENCIES += libxml2 # Apache wants the path to the header file, where it can find
package/apr/apr.mk +15 -0
@@ -35,6 +35,21 @@ endif # Fix lfs detection when cross compiling APR_CONF_ENV += apr_cv_use_lfs64=yes +# Use non-portable atomics when available: 8 bytes atomics are used on +# 64-bits architectures, 4 bytes atomics on 32-bits architectures. We +# have to override ap_cv_atomic_builtins because the test used to +# check for atomic builtins uses AC_TRY_RUN, which doesn't work when +# cross-compiling. +ifeq ($(BR2_ARCH_IS_64):$(BR2_TOOLCHAIN_HAS_SYNC_8),y:y) +APR_CONF_OPTS += --enable-nonportable-atomics +APR_CONF_ENV += ap_cv_atomic_builtins=yes +else ifeq ($(BR2_ARCH_IS_64):$(BR2_TOOLCHAIN_HAS_SYNC_4),:y) +APR_CONF_OPTS += --enable-nonportable-atomics +APR_CONF_ENV += ap_cv_atomic_builtins=yes +else +APR_CONF_OPTS += --disable-nonportable-atomics +endif + ifeq ($(BR2_PACKAGE_UTIL_LINUX_LIBUUID),y) APR_DEPENDENCIES += util-linux endif
Signature · 1 line
2.6.4
PATCH v2 5/17 apache, apr: fix atomic handling
Thomas, All,
On 2016-01-27 23:47 +0100, Thomas Petazzoni spake thusly:
Quoted 6 lines
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.
Quoted 6 lines
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_xsymbols rather thanBR2_ARCH_HAS_ATOMICS.Signed-off-by Thomas Petazzoni <[email protected]>Cc Bernd Kuhls <[email protected]>
Regards,
Yann E. MORIN.
Quoted 53 lines
--- package/apache/apache.mk | 4 ---- package/apr/apr.mk | 15 +++++++++++++++ 2 files changed, 15 insertions(+), 4 deletions(-)package/apache/apache.mk +0
-4@@ -35,10 +35,6 @@ APACHE_CONF_OPTS = \ --disable-lua \ --disable-luajit -ifeq ($(BR2_ARCH_HAS_ATOMICS),y) -APACHE_CONF_OPTS += --enable-nonportable-atomics=yes -endif - ifeq ($(BR2_PACKAGE_LIBXML2),y) APACHE_DEPENDENCIES += libxml2 # Apache wants the path to the header file, where it can findpackage/apr/apr.mk +15
-0@@ -35,6 +35,21 @@ endif # Fix lfs detection when cross compiling APR_CONF_ENV += apr_cv_use_lfs64=yes +# Use non-portable atomics when available: 8 bytes atomics are used on +# 64-bits architectures, 4 bytes atomics on 32-bits architectures. We +# have to override ap_cv_atomic_builtins because the test used to +# check for atomic builtins uses AC_TRY_RUN, which doesn't work when +# cross-compiling. +ifeq ($(BR2_ARCH_IS_64):$(BR2_TOOLCHAIN_HAS_SYNC_8),y:y) +APR_CONF_OPTS += --enable-nonportable-atomics +APR_CONF_ENV += ap_cv_atomic_builtins=yes +else ifeq ($(BR2_ARCH_IS_64):$(BR2_TOOLCHAIN_HAS_SYNC_4),:y) +APR_CONF_OPTS += --enable-nonportable-atomics +APR_CONF_ENV += ap_cv_atomic_builtins=yes +else +APR_CONF_OPTS += --disable-nonportable-atomics +endif + ifeq ($(BR2_PACKAGE_UTIL_LINUX_LIBUUID),y) APR_DEPENDENCIES += util-linux endifSignature · 6 lines
2.6.4 _______________________________________________ buildroot mailing list buildroot at busybox.net http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH v2 6/17 jack2: use the proper BR2_TOOLCHAIN_HAS_SYNC_x symbol
In reply to Thomas PetazzoniMove away from BR2_ARCH_HAS_ATOMICS and use BR2_TOOLCHAIN_HAS_SYNC_4 instead for the jack2 package and its reverse dependency.
--- package/jack2/Config.in | 4 ++-- package/mpd/Config.in | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-)
package/jack2/Config.in +2 -2
@@ -3,8 +3,8 @@ config BR2_PACKAGE_JACK2 depends on BR2_TOOLCHAIN_HAS_THREADS # alsa-lib depends on BR2_USE_MMU # fork() depends on BR2_INSTALL_LIBSTDCPP - depends on BR2_ARCH_HAS_ATOMICS depends on !BR2_STATIC_LIBS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_LIBSAMPLERATE select BR2_PACKAGE_LIBSNDFILE select BR2_PACKAGE_ALSA_LIB
@@ -23,6 +23,6 @@ config BR2_PACKAGE_JACK2 comment "jack2 needs a toolchain w/ threads, C++, dynamic library" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_INSTALL_LIBSTDCPP || \ BR2_STATIC_LIBS
package/mpd/Config.in +2 -1
@@ -230,13 +230,14 @@ config BR2_PACKAGE_MPD_HTTPD_OUTPUT config BR2_PACKAGE_MPD_JACK2 bool "jack2" - depends on BR2_ARCH_HAS_ATOMICS depends on !BR2_STATIC_LIBS # jack2 + depends on BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_JACK2 help Enable jack output support. comment "jack support needs a toolchain w/ dynamic library" + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on BR2_STATIC_LIBS config BR2_PACKAGE_MPD_OSS
Signature · 1 line
2.6.4
PATCH v2 7/17 libtorrent: use the proper BR2_TOOLCHAIN_HAS_SYNC_x symbols
In reply to Thomas Petazzonilibtorrent 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.
[yann.morin.1998 at free.fr: build-tested on an ARC toolchain without
atomics, with CPU 770D]
--- package/libtorrent/Config.in | 4 ++-- package/rtorrent/Config.in | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
package/libtorrent/Config.in +2 -2
@@ -2,7 +2,7 @@ config BR2_PACKAGE_LIBTORRENT bool "libtorrent" depends on BR2_INSTALL_LIBSTDCPP depends on BR2_TOOLCHAIN_HAS_THREADS - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_1 && BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_ZLIB help BitTorrent library written in C++ for *nix
@@ -10,5 +10,5 @@ config BR2_PACKAGE_LIBTORRENT https://github.com/rakshasa/libtorrent comment "libtorrent needs a toolchain w/ C++, threads" - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_1 && BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS
package/rtorrent/Config.in +2 -2
@@ -4,7 +4,7 @@ config BR2_PACKAGE_RTORRENT depends on BR2_USE_WCHAR depends on BR2_TOOLCHAIN_HAS_THREADS depends on BR2_USE_MMU # fork() - depends on BR2_ARCH_HAS_ATOMICS # libtorrent + depends on BR2_TOOLCHAIN_HAS_SYNC_1 && BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_LIBCURL select BR2_PACKAGE_LIBTORRENT select BR2_PACKAGE_NCURSES
@@ -16,5 +16,5 @@ config BR2_PACKAGE_RTORRENT comment "rtorrent needs a toolchain w/ C++, threads, wchar" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_1 && BR2_TOOLCHAIN_HAS_SYNC_4 depends on !(BR2_INSTALL_LIBSTDCPP && BR2_USE_WCHAR && BR2_TOOLCHAIN_HAS_THREADS)
Signature · 1 line
2.6.4
PATCH v2 8/17 gauche: disable on SPARC(64), remove atomics dependency
In reply to Thomas Petazzonigauche 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.
--- package/gauche/Config.in | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
package/gauche/Config.in +1 -4
@@ -4,14 +4,12 @@ config BR2_PACKAGE_GAUCHE_ARCH_SUPPORTS default y if BR2_arm || BR2_armeb || BR2_i386 || BR2_m68k || \ BR2_mips || BR2_mipsel || BR2_mips64 || \ BR2_mips64el || BR2_powerpc || BR2_powerpc64 || \ - BR2_powerpc64le || BR2_sh || BR2_sh64 || BR2_sparc || \ - BR2_sparc64 || BR2_x86_64 + BR2_powerpc64le || BR2_sh || BR2_sh64 || BR2_x86_64 config BR2_PACKAGE_GAUCHE bool "gauche" depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL depends on BR2_USE_MMU # fork() - depends on BR2_ARCH_HAS_ATOMICS depends on BR2_PACKAGE_GAUCHE_ARCH_SUPPORTS depends on !BR2_STATIC_LIBS help
@@ -26,6 +24,5 @@ config BR2_PACKAGE_GAUCHE comment "gauche needs a toolchain w/ NPTL, dynamic library" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS depends on BR2_PACKAGE_GAUCHE_ARCH_SUPPORTS depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL || BR2_STATIC_LIBS
Signature · 1 line
2.6.4
PATCH v2 9/17 cairo, harfbuzz: rework atomic dependencies
In reply to Thomas PetazzoniThis 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.7 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.
--- package/cairo/Config.in | 1 - package/cairo/cairo.mk | 6 ++++++ package/cairomm/Config.in | 2 -- package/cwiid/Config.in | 2 +- package/directfb/Config.in | 5 ++--- package/enlightenment/Config.in | 6 +++--- package/gstreamer/gst-plugins-bad/Config.in | 4 ++-- package/gstreamer/gst-plugins-base/Config.in | 4 ++-- package/gstreamer/gst-plugins-good/Config.in | 1 - package/gstreamer1/gst1-plugins-bad/Config.in | 4 ++-- package/gstreamer1/gst1-plugins-base/Config.in | 4 ++-- package/gstreamer1/gst1-plugins-good/Config.in | 1 - package/gtkmm3/Config.in | 4 ++-- package/harfbuzz/Config.in | 2 ++ package/libevas-generic-loaders/Config.in | 4 ++-- package/libfm/Config.in | 4 ++-- package/libgail/Config.in | 4 ++-- package/libgdiplus/Config.in | 2 -- package/libgtk2/Config.in | 4 ++-- package/libgtk3/Config.in | 4 ++-- package/librsvg/Config.in | 4 ++-- package/libsvg-cairo/Config.in | 1 - package/openbox/Config.in | 4 ++-- package/opencv/Config.in | 2 +- package/opencv3/Config.in | 4 ++-- package/pango/Config.in | 4 ++-- package/pangomm/Config.in | 4 ++-- package/pcmanfm/Config.in | 4 ++-- package/pinentry/Config.in | 4 ++-- package/rrdtool/Config.in | 2 +- package/webkit/Config.in | 4 ++-- package/webkitgtk24/Config.in | 4 ++-- package/weston/Config.in | 2 -- package/xscreensaver/Config.in | 4 ++-- 34 files changed, 56 insertions(+), 59 deletions(-)
package/cairo/Config.in +0 -1
@@ -1,6 +1,5 @@ config BR2_PACKAGE_CAIRO bool "cairo" - depends on BR2_ARCH_HAS_ATOMICS select BR2_PACKAGE_PIXMAN select BR2_PACKAGE_FONTCONFIG select BR2_PACKAGE_XLIB_LIBX11 if BR2_PACKAGE_XORG7
package/cairo/cairo.mk +6 -0
@@ -16,6 +16,12 @@ ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),) CAIRO_CONF_ENV += CPPFLAGS="$(TARGET_CPPFLAGS) -DCAIRO_NO_MUTEX=1" endif +# cairo can use C++11 atomics when available, so we need to link with +# libatomic for the architectures who need libatomic. +ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y) +CAIRO_CONF_ENV += LIBS="-latomic" +endif + CAIRO_CONF_OPTS = \ --enable-trace=no \ --enable-interpreter=no
package/cairomm/Config.in +0 -2
@@ -3,7 +3,6 @@ config BR2_PACKAGE_CAIROMM select BR2_PACKAGE_CAIRO select BR2_PACKAGE_LIBGLIB2 select BR2_PACKAGE_LIBSIGC - depends on BR2_ARCH_HAS_ATOMICS # cairo depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 # C++11 depends on BR2_TOOLCHAIN_HAS_THREADS # libglib2 depends on BR2_USE_WCHAR # libglib2
@@ -16,6 +15,5 @@ config BR2_PACKAGE_CAIROMM comment "cairomm needs a toolchain w/ C++, wchar, threads, gcc >= 4.8" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 || !BR2_USE_WCHAR \ || !BR2_TOOLCHAIN_HAS_THREADS || !BR2_INSTALL_LIBSTDCPP
package/cwiid/Config.in +1 -1
@@ -14,7 +14,7 @@ config BR2_PACKAGE_CWIID if BR2_PACKAGE_CWIID config BR2_PACKAGE_CWIID_WMGUI bool "wmgui" - depends on BR2_ARCH_HAS_ATOMICS # libgtk2 -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # libgtk3 -> pango -> harfbuzz depends on BR2_PACKAGE_XORG7 # libgtk2 depends on BR2_USE_WCHAR # libgtk2 -> libglib2 depends on BR2_TOOLCHAIN_HAS_THREADS # libgtk2 -> libglib2
package/directfb/Config.in +2 -3
@@ -4,7 +4,7 @@ config BR2_PACKAGE_DIRECTFB depends on BR2_INSTALL_LIBSTDCPP depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_5 depends on !BR2_TOOLCHAIN_USES_MUSL # sigval_t issue - depends on !BR2_sparc # needs atomic operation __sync_fetch_and_add + depends on BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_FREETYPE select BR2_PACKAGE_ZLIB help
@@ -141,7 +141,6 @@ config BR2_PACKAGE_DIRECTFB_PNG config BR2_PACKAGE_DIRECTFB_SVG bool "enable SVG support" - depends on BR2_ARCH_HAS_ATOMICS # cairo default y select BR2_PACKAGE_LIBSVG_CAIRO
@@ -157,6 +156,6 @@ config BR2_PACKAGE_DIRECTFB_TESTS endif # BR2_PACKAGE_DIRECTFB comment "directfb needs a (e)glibc or uClibc toolchain w/ C++, threads, gcc >= 4.5" - depends on !BR2_sparc # needs atomic operation __sync_fetch_and_add + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_INSTALL_LIBSTDCPP || \ !BR2_TOOLCHAIN_GCC_AT_LEAST_4_5 || BR2_TOOLCHAIN_USES_MUSL
package/enlightenment/Config.in +3 -3
@@ -10,8 +10,8 @@ config BR2_PACKAGE_ENLIGHTENMENT depends on BR2_USE_MMU depends on BR2_PACKAGE_EFL depends on BR2_PACKAGE_XORG7 - # libevas-generic-loaders-svg -> librsvg -> pango -> cairo - depends on BR2_ARCH_HAS_ATOMICS + # libevas-generic-loaders-svg -> librsvg -> pango -> harfbuzz + depends on BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_EFL_X_XLIB select BR2_PACKAGE_EFL_JPEG # needed at runtime by enlightenment_start select BR2_PACKAGE_EFL_PNG # needed at runtime by enlightenment_start
@@ -31,4 +31,4 @@ config BR2_PACKAGE_ENLIGHTENMENT comment "enlightenment needs a toolchain w/ wchar, C++, threads" depends on BR2_PACKAGE_EFL && BR2_PACKAGE_XORG7 && BR2_USE_MMU depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || !BR2_INSTALL_LIBSTDCPP - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4
package/gstreamer/gst-plugins-bad/Config.in +2 -2
@@ -298,12 +298,12 @@ config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_OPUS config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_RSVG bool "rsvg" depends on BR2_INSTALL_LIBSTDCPP # librsvg -> pango - depends on BR2_ARCH_HAS_ATOMICS # librsvg -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # librsvg -> pango -> harfbuzz select BR2_PACKAGE_LIBRSVG comment "rsvg plugin needs a toolchain w/ C++" depends on !BR2_INSTALL_LIBSTDCPP - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 config BR2_PACKAGE_GST_PLUGINS_BAD_PLUGIN_SDL bool "sdl"
package/gstreamer/gst-plugins-base/Config.in +2 -2
@@ -85,12 +85,12 @@ config BR2_PACKAGE_GST_PLUGINS_BASE_PLUGIN_OGG config BR2_PACKAGE_GST_PLUGINS_BASE_PLUGIN_PANGO bool "pango font renderer" depends on BR2_INSTALL_LIBSTDCPP # pango -> freetype - depends on BR2_ARCH_HAS_ATOMICS # pango -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pango -> harfbuzz select BR2_PACKAGE_PANGO comment "pango plugin needs a toolchain w/ C++" depends on !BR2_INSTALL_LIBSTDCPP - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 config BR2_PACKAGE_GST_PLUGINS_BASE_PLUGIN_THEORA bool "theora (*.ogg video)"
package/gstreamer/gst-plugins-good/Config.in +0 -1
@@ -174,7 +174,6 @@ config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_ANNODEX config BR2_PACKAGE_GST_PLUGINS_GOOD_PLUGIN_CAIRO bool "cairo" - depends on BR2_ARCH_HAS_ATOMICS # cairo select BR2_PACKAGE_CAIRO select BR2_PACKAGE_CAIRO_PNG
package/gstreamer1/gst1-plugins-bad/Config.in +2 -2
@@ -623,14 +623,14 @@ config BR2_PACKAGE_GST1_PLUGINS_BAD_PLUGIN_OPUS config BR2_PACKAGE_GST1_PLUGINS_BAD_PLUGIN_RSVG bool "rsvg" depends on BR2_INSTALL_LIBSTDCPP # librsvg -> pango - depends on BR2_ARCH_HAS_ATOMICS # librsvg -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # librsvg -> pango -> harfbuzz select BR2_PACKAGE_LIBRSVG help RSVG plugin library comment "rsvg plugin needs a toolchain w/ C++" depends on !BR2_INSTALL_LIBSTDCPP - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 config BR2_PACKAGE_GST1_PLUGINS_BAD_PLUGIN_GL bool "gl"
package/gstreamer1/gst1-plugins-base/Config.in +2 -2
@@ -129,14 +129,14 @@ config BR2_PACKAGE_GST1_PLUGINS_BASE_PLUGIN_OGG config BR2_PACKAGE_GST1_PLUGINS_BASE_PLUGIN_PANGO bool "pango font renderer" depends on BR2_INSTALL_LIBSTDCPP # pango -> freetype - depends on BR2_ARCH_HAS_ATOMICS # pango -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pango -> harfbuzz select BR2_PACKAGE_PANGO help Pango-based text rendering and overlay comment "pango plugin needs a toolchain w/ C++" depends on !BR2_INSTALL_LIBSTDCPP - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 config BR2_PACKAGE_GST1_PLUGINS_BASE_PLUGIN_THEORA bool "theora (*.ogg video)"
package/gstreamer1/gst1-plugins-good/Config.in +0 -1
@@ -281,7 +281,6 @@ comment "v4l2 needs a toolchain w/ headers >= 3.0" config BR2_PACKAGE_GST1_PLUGINS_GOOD_PLUGIN_CAIRO bool "cairo" - depends on BR2_ARCH_HAS_ATOMICS # cairo select BR2_PACKAGE_CAIRO select BR2_PACKAGE_CAIRO_PNG help
package/gtkmm3/Config.in +2 -2
@@ -5,7 +5,7 @@ config BR2_PACKAGE_GTKMM3 # and GCC >= 5.3. # https://sourceware.org/bugzilla/show_bug.cgi?id=19405 depends on !BR2_nios2 - depends on BR2_ARCH_HAS_ATOMICS # libcairomm/libgtk3/libpangomm -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pangomm, libgtk3 -> pango -> harfbuzz depends on BR2_INSTALL_LIBSTDCPP # glibmm, libpangomm -> glibmm/pango depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 # C++11 depends on BR2_TOOLCHAIN_HAS_THREADS # *mm/libgtk3 -> libglib2
@@ -24,6 +24,6 @@ config BR2_PACKAGE_GTKMM3 comment "gtkmm3 needs a toolchain w/ C++, wchar, threads, gcc >= 4.8" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 || !BR2_USE_WCHAR \ || !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS
package/harfbuzz/Config.in +2 -0
@@ -1,6 +1,7 @@ config BR2_PACKAGE_HARFBUZZ bool "harfbuzz" depends on BR2_INSTALL_LIBSTDCPP + depends on BR2_TOOLCHAIN_HAS_SYNC_4 help HarfBuzz is an OpenType text shaping engine
@@ -10,4 +11,5 @@ config BR2_PACKAGE_HARFBUZZ glib2 and icu packages if they are selected. comment "harfbuzz needs a toolchain w/ C++" + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_INSTALL_LIBSTDCPP
package/libevas-generic-loaders/Config.in +2 -2
@@ -27,14 +27,14 @@ config BR2_PACKAGE_LIBEVAS_GENERIC_LOADERS_SVG depends on BR2_USE_WCHAR # librsvg -> glib2 depends on BR2_TOOLCHAIN_HAS_THREADS # librsvg -> glib2 depends on BR2_INSTALL_LIBSTDCPP # librsvg -> pango - depends on BR2_ARCH_HAS_ATOMICS # cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # librsvg -> pango -> harfbuzz select BR2_PACKAGE_LIBRSVG select BR2_PACKAGE_CAIRO help This option enables the Evas generic SVG loader comment "SVG loader needs a toolchain w/ wchar, threads, C++" - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on BR2_USE_MMU depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || !BR2_INSTALL_LIBSTDCPP
package/libfm/Config.in +2 -2
@@ -9,7 +9,7 @@ config BR2_PACKAGE_LIBFM depends on BR2_TOOLCHAIN_HAS_THREADS # libglib2 depends on BR2_USE_MMU # libglib2 depends on BR2_INSTALL_LIBSTDCPP # libgtk2 - depends on BR2_ARCH_HAS_ATOMICS # libgtk2 + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # libgtk2 -> pango -> harfbuzz help A glib/gio-based library providing some file management utilities and related-widgets missing in gtk+/glib. This is
@@ -23,6 +23,6 @@ config BR2_PACKAGE_LIBFM comment "libfm needs X.org and a toolchain w/ wchar, threads, C++" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR || !BR2_INSTALL_LIBSTDCPP || \ !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_XORG7
package/libgail/Config.in +2 -2
@@ -4,7 +4,7 @@ config BR2_PACKAGE_LIBGAIL depends on BR2_TOOLCHAIN_HAS_THREADS # pango -> libglib2 depends on BR2_USE_MMU # pango -> libglib2 depends on BR2_INSTALL_LIBSTDCPP # pango -> freetype - depends on BR2_ARCH_HAS_ATOMICS # pango -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pango -> harfbuzz depends on BR2_PACKAGE_LIBGTK2 depends on BR2_DEPRECATED_SINCE_2015_08 select BR2_PACKAGE_PANGO
@@ -27,5 +27,5 @@ comment "libgail needs a toolchain w/ C++, wchar, threads" depends on BR2_PACKAGE_LIBGTK2 depends on !BR2_INSTALL_LIBSTDCPP || !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on BR2_DEPRECATED_SINCE_2015_08
package/libgdiplus/Config.in +0 -2
@@ -8,7 +8,6 @@ config BR2_PACKAGE_LIBGDIPLUS depends on BR2_USE_WCHAR # libglib2 -> gettext depends on BR2_TOOLCHAIN_HAS_THREADS # libglib2 depends on BR2_USE_MMU # libglib2 - depends on BR2_ARCH_HAS_ATOMICS # cairo help An Open Source implementation of the GDI+ API.
@@ -16,6 +15,5 @@ config BR2_PACKAGE_LIBGDIPLUS comment "libgdiplus needs a toolchain w/ wchar, threads" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS depends on BR2_PACKAGE_XORG7 depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
package/libgtk2/Config.in +2 -2
@@ -17,7 +17,7 @@ config BR2_PACKAGE_LIBGTK2 depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 depends on BR2_USE_MMU # glib2 depends on BR2_INSTALL_LIBSTDCPP # pango - depends on BR2_ARCH_HAS_ATOMICS # cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pango -> harfbuzz help The GTK+ version 2 graphical user interface library
@@ -35,7 +35,7 @@ endif comment "libgtk2 needs a toolchain w/ wchar, threads, C++" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on BR2_PACKAGE_XORG7 depends on !BR2_USE_WCHAR || !BR2_INSTALL_LIBSTDCPP || \ !BR2_TOOLCHAIN_HAS_THREADS
package/libgtk3/Config.in +2 -2
@@ -15,7 +15,7 @@ config BR2_PACKAGE_LIBGTK3 depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 depends on BR2_USE_MMU # glib2 depends on BR2_INSTALL_LIBSTDCPP # pango - depends on BR2_ARCH_HAS_ATOMICS # cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pango -> harfbuzz help The GTK+ version 3 graphical user interface library
@@ -84,6 +84,6 @@ endif comment "libgtk3 needs a toolchain w/ wchar, threads, C++" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR || !BR2_INSTALL_LIBSTDCPP || \ !BR2_TOOLCHAIN_HAS_THREADS
package/librsvg/Config.in +2 -2
@@ -11,7 +11,7 @@ config BR2_PACKAGE_LIBRSVG depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 depends on BR2_USE_MMU # glib2 depends on BR2_INSTALL_LIBSTDCPP # pango - depends on BR2_ARCH_HAS_ATOMICS # cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pango -> harfbuzz help The rsvg library is an efficient renderer for Scalable Vector Graphics (SVG) pictures.
@@ -20,5 +20,5 @@ config BR2_PACKAGE_LIBRSVG comment "librsvg needs a toolchain w/ wchar, threads, C++" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS # cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || !BR2_INSTALL_LIBSTDCPP
package/libsvg-cairo/Config.in +0 -1
@@ -1,6 +1,5 @@ config BR2_PACKAGE_LIBSVG_CAIRO bool "libsvg-cairo" - depends on BR2_ARCH_HAS_ATOMICS # cairo select BR2_PACKAGE_CAIRO select BR2_PACKAGE_CAIRO_SVG select BR2_PACKAGE_LIBSVG
package/openbox/Config.in +2 -2
@@ -4,7 +4,7 @@ config BR2_PACKAGE_OPENBOX depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 depends on BR2_USE_MMU # glib2 depends on BR2_USE_WCHAR # glib2 - depends on BR2_ARCH_HAS_ATOMICS # pango -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pango -> harfbuzz depends on BR2_INSTALL_LIBSTDCPP # pango -> freetype select BR2_PACKAGE_LIBGLIB2 select BR2_PACKAGE_LIBXML2
@@ -21,7 +21,7 @@ config BR2_PACKAGE_OPENBOX comment "openbox needs a toolchain w/ C++, threads, wchar" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_USE_WCHAR || \ !BR2_INSTALL_LIBSTDCPP depends on BR2_PACKAGE_XORG7
package/opencv/Config.in +1 -1
@@ -179,7 +179,7 @@ config BR2_PACKAGE_OPENCV_WITH_GTK depends on BR2_TOOLCHAIN_HAS_THREADS # libgtk2 -> libglib2 depends on BR2_INSTALL_LIBSTDCPP depends on BR2_USE_MMU # libgtk2 -> glib2 - depends on BR2_ARCH_HAS_ATOMICS # libgtk2 -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # libgtk2 -> pango -> harfbuzz depends on BR2_PACKAGE_OPENCV_LIB_HIGHGUI select BR2_PACKAGE_LIBGTK2
package/opencv3/Config.in +2 -2
@@ -69,7 +69,7 @@ config BR2_PACKAGE_OPENCV3_WITH_GTK comment "gtk2 support needs libgtk2" depends on BR2_USE_MMU # libgtk2 -> glib2 - depends on BR2_ARCH_HAS_ATOMICS # libgtk2 -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_PACKAGE_LIBGTK2 config BR2_PACKAGE_OPENCV3_WITH_GTK3
@@ -78,7 +78,7 @@ config BR2_PACKAGE_OPENCV3_WITH_GTK3 comment "gtk3 support needs libgtk3" depends on BR2_USE_MMU # libgtk3 -> glib2 - depends on BR2_ARCH_HAS_ATOMICS # libgtk3 -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_PACKAGE_LIBGTK3 config BR2_PACKAGE_OPENCV3_WITH_QT
package/pango/Config.in +2 -2
@@ -4,7 +4,7 @@ config BR2_PACKAGE_PANGO depends on BR2_TOOLCHAIN_HAS_THREADS # glib2 depends on BR2_USE_MMU # glib2 depends on BR2_INSTALL_LIBSTDCPP # freetype support - depends on BR2_ARCH_HAS_ATOMICS # cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # harfbuzz select BR2_PACKAGE_LIBGLIB2 select BR2_PACKAGE_EXPAT select BR2_PACKAGE_CAIRO
@@ -24,6 +24,6 @@ config BR2_PACKAGE_PANGO comment "pango needs a toolchain w/ wchar, threads, C++" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || \ !BR2_INSTALL_LIBSTDCPP
package/pangomm/Config.in +2 -2
@@ -4,7 +4,7 @@ config BR2_PACKAGE_PANGOMM select BR2_PACKAGE_GLIBMM select BR2_PACKAGE_PANGO select BR2_PACKAGE_LIBSIGC - depends on BR2_ARCH_HAS_ATOMICS # libcairomm/pango -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pango -> harfbuzz depends on BR2_INSTALL_LIBSTDCPP # glibmm/pango depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 # C++11 depends on BR2_TOOLCHAIN_HAS_THREADS # *mm/pango -> libglib2
@@ -17,6 +17,6 @@ config BR2_PACKAGE_PANGOMM comment "pangomm needs a toolchain w/ C++, wchar, threads, gcc >= 4.8" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 || !BR2_USE_WCHAR \ || !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS
package/pcmanfm/Config.in +2 -2
@@ -9,7 +9,7 @@ config BR2_PACKAGE_PCMANFM depends on BR2_TOOLCHAIN_HAS_THREADS # libglib2 depends on BR2_USE_MMU # libglib2 depends on BR2_INSTALL_LIBSTDCPP # libgtk2 - depends on BR2_ARCH_HAS_ATOMICS # libgtk2 + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # libgtk2 -> pango -> harfbuzz help PCMan File Manager (PCManFM) is a file manager application developed by Hong Jen Yee from Taiwan which is meant to be a replacement for
@@ -19,6 +19,6 @@ config BR2_PACKAGE_PCMANFM comment "pcmanfm needs X.org and a toolchain w/ wchar, threads, C++" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR || !BR2_INSTALL_LIBSTDCPP || \ !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_XORG7
package/pinentry/Config.in +2 -2
@@ -23,7 +23,7 @@ config BR2_PACKAGE_PINENTRY_GTK2 depends on BR2_TOOLCHAIN_HAS_THREADS depends on BR2_USE_MMU depends on BR2_INSTALL_LIBSTDCPP - depends on BR2_ARCH_HAS_ATOMICS # libgtk2 -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # libgtk2 -> pango -> harfbuzz select BR2_PACKAGE_LIBGTK2 select BR2_PACKAGE_LIBICONV if !BR2_ENABLE_LOCALE help
@@ -31,7 +31,7 @@ config BR2_PACKAGE_PINENTRY_GTK2 comment "pinentry-gtk2 needs X and a toolchain w/ wchar, threads, C++" depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_PACKAGE_XORG7 || !BR2_USE_WCHAR || \ !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS
package/rrdtool/Config.in +1 -1
@@ -15,7 +15,7 @@ if BR2_PACKAGE_RRDTOOL config BR2_PACKAGE_RRDTOOL_RRDGRAPH bool "rrd_graph" default y - depends on BR2_ARCH_HAS_ATOMICS # cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # pango -> harfbuzz depends on BR2_INSTALL_LIBSTDCPP # freetype support from pango select BR2_PACKAGE_CAIRO select BR2_PACKAGE_CAIRO_PDF
package/webkit/Config.in +2 -2
@@ -18,7 +18,7 @@ config BR2_PACKAGE_WEBKIT depends on BR2_PACKAGE_LIBGTK2 depends on BR2_PACKAGE_WEBKIT_ARCH_SUPPORTS depends on !BR2_BINFMT_FLAT # icu - depends on BR2_ARCH_HAS_ATOMICS # cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # harfbuzz select BR2_PACKAGE_CAIRO select BR2_PACKAGE_CAIRO_PNG select BR2_PACKAGE_ENCHANT
@@ -47,7 +47,7 @@ config BR2_PACKAGE_WEBKIT comment "webkit needs libgtk2 and a toolchain w/ C++, wchar, threads" depends on BR2_DEPRECATED_SINCE_2015_08 depends on BR2_PACKAGE_WEBKIT_ARCH_SUPPORTS - depends on BR2_ARCH_HAS_ATOMICS # cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_PACKAGE_LIBGTK2 || !BR2_INSTALL_LIBSTDCPP || \ !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS depends on BR2_USE_MMU
package/webkitgtk24/Config.in +2 -2
@@ -11,7 +11,7 @@ config BR2_PACKAGE_WEBKITGTK24_ARCH_SUPPORTS comment "webkitgtk24 needs libgtk2 and a toolchain w/ C++, wchar, NPTL, gcc >=4.8" depends on BR2_PACKAGE_WEBKITGTK24_ARCH_SUPPORTS - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_PACKAGE_LIBGTK2 || !BR2_PACKAGE_XORG7 || \ !BR2_TOOLCHAIN_HAS_THREADS_NPTL || !BR2_INSTALL_LIBSTDCPP \ || !BR2_USE_WCHAR || !BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
@@ -25,7 +25,7 @@ config BR2_PACKAGE_WEBKITGTK24 depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 depends on (BR2_PACKAGE_LIBGTK2 && BR2_PACKAGE_XORG7) depends on BR2_PACKAGE_WEBKITGTK24_ARCH_SUPPORTS - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # harfbuzz select BR2_PACKAGE_CAIRO select BR2_PACKAGE_CAIRO_PNG select BR2_PACKAGE_ENCHANT
package/weston/Config.in +0 -2
@@ -1,5 +1,4 @@ comment "weston needs udev and a toolchain w/ locale, threads, dynamic library, headers >= 3.0" - depends on BR2_ARCH_HAS_ATOMICS depends on !BR2_PACKAGE_HAS_UDEV || !BR2_TOOLCHAIN_HAS_THREADS || \ !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 || BR2_STATIC_LIBS || \ !BR2_ENABLE_LOCALE
@@ -19,7 +18,6 @@ config BR2_PACKAGE_WESTON depends on !BR2_STATIC_LIBS # wayland depends on BR2_TOOLCHAIN_HAS_THREADS # wayland depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_0 - depends on BR2_ARCH_HAS_ATOMICS # cairo # Runtime dependency select BR2_PACKAGE_XKEYBOARD_CONFIG # Make sure at least one compositor is selected.
package/xscreensaver/Config.in +2 -2
@@ -5,7 +5,7 @@ config BR2_PACKAGE_XSCREENSAVER depends on BR2_TOOLCHAIN_HAS_THREADS # libgtk2 -> glib2 depends on BR2_USE_WCHAR # libgtk2 -> glib2 depends on BR2_USE_MMU # libgtk2 -> glib2 - depends on BR2_ARCH_HAS_ATOMICS # libgtk2 -> cairo + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # libgtk2 -> pango -> harfbuzz select BR2_PACKAGE_LIBGTK2 select BR2_PACKAGE_LIBGLADE select BR2_PACKAGE_JPEG
@@ -25,6 +25,6 @@ config BR2_PACKAGE_XSCREENSAVER comment "xscreensaver needs a toolchain w/ wchar, C++, threads" depends on BR2_PACKAGE_XORG7 depends on BR2_USE_MMU - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS || \ !BR2_USE_WCHAR
Signature · 1 line
2.6.4
PATCH v2 10/17 squid: rework atomic handling
In reply to Thomas Petazzonisquid 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.
--- package/squid/squid.mk | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
package/squid/squid.mk +4 -6
@@ -41,12 +41,10 @@ SQUID_CONF_OPTS = \ --with-swapdir=/var/cache/squid/ \ --with-default-user=squid -# Atomics in Squid use __sync_add_and_fetch_8, i.e a 64 bits atomic -# operation. This atomic intrinsic is only available natively on -# 64-bit architectures that have atomic operations. On 32-bit -# architectures, it would be provided by libatomic, but Buildroot -# typically doesn't provide it. -ifeq ($(BR2_ARCH_HAS_ATOMICS)$(BR2_ARCH_IS_64),yy) +# Atomics in Squid use __sync built-ins on 4 and 8 bytes. However, the +# configure script tests them using AC_TRY_RUN, so we have to give +# some hints. +ifeq ($(BR2_TOOLCHAIN_HAS_SYNC_4)$(BR2_TOOLCHAIN_HAS_SYNC_8),yy) SQUID_CONF_ENV += squid_cv_gnu_atomics=yes else SQUID_CONF_ENV += squid_cv_gnu_atomics=no
Signature · 1 line
2.6.4
PATCH v2 11/17 thrift: remove BR2_ARCH_HAS_ATOMICS dependency
In reply to Thomas Petazzonithrift 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.
[yann.morin.1998 at free.fr: build-tested on an ARC toolchain without
atomics, with CPU 770D]
--- package/thrift/Config.in | 2 -- 1 file changed, 2 deletions(-)
package/thrift/Config.in +0 -2
@@ -3,7 +3,6 @@ config BR2_PACKAGE_THRIFT depends on BR2_INSTALL_LIBSTDCPP depends on BR2_USE_WCHAR depends on BR2_TOOLCHAIN_HAS_THREADS - depends on BR2_ARCH_HAS_ATOMICS depends on BR2_PACKAGE_BOOST_ARCH_SUPPORTS select BR2_PACKAGE_BOOST select BR2_PACKAGE_LIBEVENT
@@ -20,7 +19,6 @@ config BR2_PACKAGE_THRIFT http://thrift.apache.org/ comment "thrift needs a toolchain w/ C++, wchar, threads" - depends on BR2_ARCH_HAS_ATOMICS depends on BR2_PACKAGE_BOOST_ARCH_SUPPORTS depends on !BR2_USE_WCHAR || \ !BR2_TOOLCHAIN_HAS_THREADS || !BR2_INSTALL_LIBSTDCPP
Signature · 1 line
2.6.4
PATCH v2 12/17 msgpack: rework BR2_ARCH_HAS_ATOMICS dependency
In reply to Thomas PetazzoniThe 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.
--- package/msgpack/Config.in | 4 ++-- package/python-msgpack/Config.in | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
package/msgpack/Config.in +2 -2
@@ -1,7 +1,7 @@ config BR2_PACKAGE_MSGPACK bool "msgpack" depends on BR2_INSTALL_LIBSTDCPP - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 help MessagePack is an efficient binary serialization format.
@@ -11,5 +11,5 @@ config BR2_PACKAGE_MSGPACK http://msgpack.org/ comment "msgpack needs a toolchain w/ C++" - depends on BR2_ARCH_HAS_ATOMICS depends on !BR2_INSTALL_LIBSTDCPP + depends on BR2_TOOLCHAIN_HAS_SYNC_4
package/python-msgpack/Config.in +2 -2
@@ -3,7 +3,7 @@ config BR2_PACKAGE_PYTHON_MSGPACK depends on BR2_PACKAGE_PYTHON select BR2_PACKAGE_MSGPACK depends on BR2_INSTALL_LIBSTDCPP # msgpack - depends on BR2_ARCH_HAS_ATOMICS # msgpack + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # msgpack help MessagePack (http://msgpack.org/) is a fast, compact binary serialization format, suitable for similar data to JSON.
@@ -13,6 +13,6 @@ config BR2_PACKAGE_PYTHON_MSGPACK https://pypi.python.org/pypi/msgpack-python/ comment "python-msgpack needs a toolchain w/ C++" - depends on BR2_ARCH_HAS_ATOMICS + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on BR2_PACKAGE_PYTHON depends on !BR2_INSTALL_LIBSTDCPP
Signature · 1 line
2.6.4
PATCH v2 13/17 arch: remove BR2_ARCH_HAS_ATOMICS option
In reply to Thomas PetazzoniNow that BR2_ARCH_HAS_ATOMICS is no longer used anywhere, we can remove it from arch/Config.in*, as well as from the documentation.
--- arch/Config.in | 4 ---- arch/Config.in.aarch64 | 3 --- arch/Config.in.arc | 3 --- arch/Config.in.arm | 3 --- arch/Config.in.bfin | 3 --- arch/Config.in.m68k | 3 --- arch/Config.in.microblaze | 3 --- arch/Config.in.mips | 3 --- arch/Config.in.nios2 | 3 --- arch/Config.in.powerpc | 3 --- arch/Config.in.sh | 3 --- arch/Config.in.x86 | 3 --- arch/Config.in.xtensa | 3 --- docs/manual/adding-packages-directory.txt | 5 ----- 14 files changed, 45 deletions(-)
arch/Config.in +0 -4
@@ -284,10 +284,6 @@ config BR2_GCC_TARGET_FLOAT_ABI config BR2_GCC_TARGET_MODE string -# If the architecture has atomic operations, select this: -config BR2_ARCH_HAS_ATOMICS - bool - # Must be selected by binary formats that support shared libraries. config BR2_BINFMT_SUPPORTS_SHARED bool
arch/Config.in.aarch64 +0 -3
@@ -5,6 +5,3 @@ config BR2_ARCH config BR2_ENDIAN default "LITTLE" if BR2_aarch64 default "BIG" if BR2_aarch64_be - -config BR2_ARCH_HAS_ATOMICS - default y
arch/Config.in.arc +0 -3
@@ -21,9 +21,6 @@ config BR2_ARC_ATOMIC_EXT bool "Atomic extension (LLOCK/SCOND instructions)" default y if BR2_arc770d || BR2_archs38 -config BR2_ARCH_HAS_ATOMICS - default y if BR2_ARC_ATOMIC_EXT - config BR2_ARCH default "arc" if BR2_arcle default "arceb" if BR2_arceb
arch/Config.in.arm +0 -3
@@ -426,9 +426,6 @@ config BR2_ENDIAN default "LITTLE" if BR2_arm default "BIG" if BR2_armeb -config BR2_ARCH_HAS_ATOMICS - default y - config BR2_GCC_TARGET_CPU default "arm920t" if BR2_arm920t default "arm922t" if BR2_arm922t
arch/Config.in.bfin +0 -3
@@ -68,9 +68,6 @@ config BR2_ARCH config BR2_ENDIAN default "LITTLE" -config BR2_ARCH_HAS_ATOMICS - default y - config BR2_GCC_TARGET_CPU default bf606 if BR2_bf606 default bf607 if BR2_bf607
arch/Config.in.m68k +0 -3
@@ -4,9 +4,6 @@ config BR2_ARCH config BR2_ENDIAN default "BIG" -config BR2_ARCH_HAS_ATOMICS - default y - config BR2_GCC_TARGET_ARCH default "68000" if BR2_m68k_68000 default "68010" if BR2_m68k_68010
arch/Config.in.microblaze +0 -3
@@ -9,6 +9,3 @@ config BR2_ENDIAN config BR2_microblaze bool default y if BR2_microblazeel || BR2_microblazebe - -config BR2_ARCH_HAS_ATOMICS - default y
arch/Config.in.mips +0 -3
@@ -67,9 +67,6 @@ config BR2_ENDIAN default "LITTLE" if BR2_mipsel || BR2_mips64el default "BIG" if BR2_mips || BR2_mips64 -config BR2_ARCH_HAS_ATOMICS - default y - config BR2_GCC_TARGET_ARCH default "mips32" if BR2_mips_32 default "mips32r2" if BR2_mips_32r2
arch/Config.in.nios2 +0 -3
@@ -3,6 +3,3 @@ config BR2_ARCH config BR2_ENDIAN default "LITTLE" - -config BR2_ARCH_HAS_ATOMICS - default y
arch/Config.in.powerpc +0 -3
@@ -164,9 +164,6 @@ config BR2_ENDIAN default "BIG" if BR2_powerpc || BR2_powerpc64 default "LITTLE" if BR2_powerpc64le -config BR2_ARCH_HAS_ATOMICS - default y - config BR2_GCC_TARGET_CPU default "401" if BR2_powerpc_401 default "403" if BR2_powerpc_403
arch/Config.in.sh +0 -3
@@ -28,6 +28,3 @@ config BR2_ARCH config BR2_ENDIAN default "LITTLE" if BR2_sh4 || BR2_sh4a || BR2_sh64 default "BIG" if BR2_sh2a || BR2_sh4eb || BR2_sh4aeb - -config BR2_ARCH_HAS_ATOMICS - default y
arch/Config.in.x86 +0 -3
@@ -245,9 +245,6 @@ config BR2_ARCH config BR2_ENDIAN default "LITTLE" -config BR2_ARCH_HAS_ATOMICS - default y if !BR2_x86_i386 - config BR2_GCC_TARGET_ARCH default "i386" if BR2_x86_i386 default "i486" if BR2_x86_i486
arch/Config.in.xtensa +0 -3
@@ -54,6 +54,3 @@ config BR2_ENDIAN config BR2_ARCH default "xtensa" if BR2_xtensa - -config BR2_ARCH_HAS_ATOMICS - default y
docs/manual/adding-packages-directory.txt +0 -5
@@ -274,11 +274,6 @@ use in the comment. ** Dependency symbol: +BR2_USE_MMU+ ** Comment string: no comment to be added -* Atomic instructions (whereby the architecture has instructions to - perform some operations atomically, like LOCKCMPXCHG on x86) -** Dependency symbol: +BR2_ARCH_HAS_ATOMICS+ -** Comment string: no comment to be added - * Gcc +__sync_*+ built-ins used for atomic operations. They are available in variants operating on 1 byte, 2 bytes, 4 bytes and 8 bytes. Since different architectures support atomic operations on
Signature · 1 line
2.6.4
PATCH v2 14/17 glog: fix atomic built-in problem
In reply to Thomas Petazzoniglog 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/
--- package/glog/glog.mk | 11 +++++++++++ 1 file changed, 11 insertions(+)
package/glog/glog.mk +11 -0
@@ -14,4 +14,15 @@ ifeq ($(BR2_PACKAGE_GFLAGS),y) GLOG_DEPENDENCIES = gflags endif +# glog can optionally use atomic __sync built-ins. However, its +# configure script only checks for the availability of the 4 bytes +# version, but the code also uses the 1 byte version. While this works +# on most architectures, it does not on architectures that implement +# only the 4 bytes version, such as Microblaze. So if the architecture +# does not implement the 1 byte version, we hint the configure script +# that atomic built-ins should not be used. +ifeq ($(BR2_TOOLCHAIN_HAS_SYNC_1),) +GLOG_CONF_ENV += ac_cv___sync_val_compare_and_swap=no +endif + $(eval $(autotools-package))
Signature · 1 line
2.6.4
PATCH v2 15/17 openal: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
In reply to Thomas PetazzoniFixes:
http://autobuild.buildroot.org/results/314fb8da3ca87984e9240d67ff233e2f999ae89e/
--- package/gstreamer1/gst1-plugins-bad/Config.in | 2 ++ package/openal/Config.in | 2 ++ 2 files changed, 4 insertions(+)
package/gstreamer1/gst1-plugins-bad/Config.in +2 -0
@@ -566,9 +566,11 @@ config BR2_PACKAGE_GST1_PLUGINS_BAD_PLUGIN_OPENAL bool "openal" depends on BR2_INSTALL_LIBSTDCPP depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL + depends on BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_OPENAL comment "openal plugin needs a toolchain w/ NPTL, C++" + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL \ || !BR2_INSTALL_LIBSTDCPP
package/openal/Config.in +2 -0
@@ -2,6 +2,7 @@ config BR2_PACKAGE_OPENAL bool "openal" depends on BR2_INSTALL_LIBSTDCPP depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL + depends on BR2_TOOLCHAIN_HAS_SYNC_4 help OpenAL provides capabilities for playing audio in a virtual 3D environment. Distance attenuation, doppler shift, and
@@ -11,5 +12,6 @@ config BR2_PACKAGE_OPENAL http://kcat.strangesoft.net/openal.html comment "openal needs a toolchain w/ NPTL, C++" + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL \ || !BR2_INSTALL_LIBSTDCPP
Signature · 1 line
2.6.4
PATCH v2 15/17 openal: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
Hi Thomas,
Isn't openal looking for the atomic functions and not for the sync ones? As seen in the URL you provided:
libopenal.so.1.17.1: undefined reference to __atomic_fetch_sub_4' libopenal.so.1.17.1: undefined reference to __atomic_compare_exchange_4' libopenal.so.1.17.1: undefined reference to `__atomic_fetch_add_4'
Am 27.01.2016 um 23:47 schrieb Thomas Petazzoni:
Quoted 47 lines
Fixes:
http://autobuild.buildroot.org/results/314fb8da3ca87984e9240d67ff233e2f999ae89e/
Signed-off-by Thomas Petazzoni <[email protected]>Acked-by "Yann E. MORIN" <[email protected]>--- package/gstreamer1/gst1-plugins-bad/Config.in | 2 ++ package/openal/Config.in | 2 ++ 2 files changed, 4 insertions(+)package/gstreamer1/gst1-plugins-bad/Config.in +2
-0@@ -566,9 +566,11 @@ config BR2_PACKAGE_GST1_PLUGINS_BAD_PLUGIN_OPENAL bool "openal" depends on BR2_INSTALL_LIBSTDCPP depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL + depends on BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_OPENAL comment "openal plugin needs a toolchain w/ NPTL, C++" + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL \ || !BR2_INSTALL_LIBSTDCPPpackage/openal/Config.in +2
-0@@ -2,6 +2,7 @@ config BR2_PACKAGE_OPENAL bool "openal" depends on BR2_INSTALL_LIBSTDCPP depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL + depends on BR2_TOOLCHAIN_HAS_SYNC_4 help OpenAL provides capabilities for playing audio in a virtual 3D environment. Distance attenuation, doppler shift, and@@ -11,5 +12,6 @@ config BR2_PACKAGE_OPENAL http://kcat.strangesoft.net/openal.html comment "openal needs a toolchain w/ NPTL, C++" + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_TOOLCHAIN_HAS_THREADS_NPTL \ || !BR2_INSTALL_LIBSTDCPP
PATCH v2 15/17 openal: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
Andr?,
Quoted 8 lines · Andr? Hentschel
Hi Thomas,
Isn't openal looking for the atomic functions and not for the sync ones? As seen in the URL you provided:
libopenal.so.1.17.1: undefined reference to
__atomic_fetch_sub_4' libopenal.so.1.17.1: undefined reference to__atomic_compare_exchange_4' libopenal.so.1.17.1: undefined reference to `__atomic_fetch_add_4'
Hum, you are right indeed. I will look into this again, but if it's a dependency on __atomic functions, then it should depend on gcc >= 4.7 *and* link with libatomic.
Thanks for reviewing!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 15/17 openal: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
Hi,
Am 30.01.2016 um 00:06 schrieb Thomas Petazzoni:
Quoted 8 lines
Andr?,
Quoted 5 lines · Andr? Hentschel
Hi Thomas,
Isn't openal looking for the atomic functions and not for the sync ones? As seen in the URL you provided:
Quoted 7 lines
Quoted 3 lines
libopenal.so.1.17.1: undefined reference to
__atomic_fetch_sub_4' libopenal.so.1.17.1: undefined reference to__atomic_compare_exchange_4' libopenal.so.1.17.1: undefined reference to `__atomic_fetch_add_4'Hum, you are right indeed. I will look into this again, but if it's a dependency on
__atomicfunctions, then it should depend on gcc >= 4.7 *and* link with libatomic.
I looked a bit closer and openal has its own checks for availability of sync/atomic functions... So the dependecy is something like (gcc >= 4.7 || has_sync_4)
Not sure how to make it link to libatomic without patching...
PATCH v2 15/17 openal: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
Hello,
Quoted 7 lines · Andr? Hentschel
Quoted 3 lines
Hum, you are right indeed. I will look into this again, but if it's a dependency on
__atomicfunctions, then it should depend on gcc >= 4.7 *and* link with libatomic.I looked a bit closer and openal has its own checks for availability of sync/atomic functions... So the dependecy is something like (gcc >= 4.7 ||
has_sync_4)
Not sure how to make it link to libatomic without patching...
I sent a new version of the patch, which hopefully resolves the problem. See the V3 of my atomic patch series.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 16/17 freerdp: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
In reply to Thomas PetazzoniFixes:
http://autobuild.buildroot.org/results/0501e63cbebe4cda4012ace6f7ec5f43342be5c5/
--- package/freerdp/Config.in | 2 ++ package/weston/Config.in | 2 ++ 2 files changed, 4 insertions(+)
package/freerdp/Config.in +2 -0
@@ -8,6 +8,7 @@ config BR2_PACKAGE_FREERDP depends on !BR2_STATIC_LIBS # uses dlfcn.h depends on BR2_TOOLCHAIN_HAS_THREADS depends on BR2_USE_MMU # libglib2 + depends on BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_OPENSSL select BR2_PACKAGE_ZLIB select BR2_PACKAGE_LIBGLIB2
@@ -84,5 +85,6 @@ config BR2_PACKAGE_FREERDP_CLIENT_WL endif comment "freerdp needs a toolchain w/ wchar, dynamic library, threads, C++" + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR || BR2_STATIC_LIBS \ || !BR2_TOOLCHAIN_HAS_THREADS || !BR2_INSTALL_LIBSTDCPP
package/weston/Config.in +2 -0
@@ -44,6 +44,7 @@ config BR2_PACKAGE_WESTON_RDP bool "RDP compositor" depends on BR2_USE_WCHAR # freerdp depends on BR2_USE_MMU # freerdp, libglib2 + depends on BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_FREERDP select BR2_PACKAGE_WESTON_HAS_COMPOSITOR help
@@ -61,6 +62,7 @@ config BR2_PACKAGE_WESTON_RDP comment "RDP compositor needs a toolchain w/ wchar" depends on BROKEN # needs FreeRDP master + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR # rpi-userland is an EGL/GLES provider, so we can't select it
Signature · 1 line
2.6.4
PATCH v2 17/17 neard: add missing BR2_TOOLCHAIN_HAS_SYNC_4 dependency
In reply to Thomas PetazzoniFixes:
http://autobuild.buildroot.org/results/b8bf7be2efd8e8e369abdde0a5bec564e8cd6f23/
--- package/connman/Config.in | 1 + package/neard/Config.in | 2 ++ 2 files changed, 3 insertions(+)
package/connman/Config.in +1 -0
@@ -50,6 +50,7 @@ config BR2_PACKAGE_CONNMAN_LOOPBACK config BR2_PACKAGE_CONNMAN_NEARD bool "enable neard support" select BR2_PACKAGE_NEARD + depends on BR2_TOOLCHAIN_HAS_SYNC_4 # neard config BR2_PACKAGE_CONNMAN_OFONO bool "enable ofono support"
package/neard/Config.in +2 -0
@@ -4,6 +4,7 @@ config BR2_PACKAGE_NEARD depends on BR2_TOOLCHAIN_HAS_THREADS # libnl, dbus, libglib2 depends on BR2_USE_MMU # dbus, libglib2 depends on !BR2_STATIC_LIBS # dlopen + depends on BR2_TOOLCHAIN_HAS_SYNC_4 select BR2_PACKAGE_DBUS select BR2_PACKAGE_LIBGLIB2 select BR2_PACKAGE_LIBNL
@@ -26,4 +27,5 @@ endif comment "neard needs a toolchain w/ wchar, threads, dynamic library" depends on BR2_USE_MMU + depends on BR2_TOOLCHAIN_HAS_SYNC_4 depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS
Signature · 1 line
2.6.4
v2 cover Rework atomic handling
In reply to Thomas PetazzoniHello Thomas,
recently, I was doing some tests on MicroBlaze and discovered that I am missing the atomic operations there. Then I could see this patch series. Thanks for that, however, I have still issues with this.
The libatomic_ops claims to not support MicroBlaze in its Config.in. So it is not possible to use either __sync_* ones nor __atomic_* ones. Even if I change this and enable it for BR2_microblaze, I am unable to compile the libatomic_ops properly (with the Buildroot toolchain 4.9.x).
Moreover, I've read somewhere that the new GCC connects the __sync_* interface to the __atomic_* interface internally. Is it true? Is this done by the libatomic_ops library? I am confused by this situation... I made some wrappers doing the __sync_* to __atomic_* translation but still with no success.
This is a snippet from my build log:
atomic_ops.c:97:1: error: unknown type name ?AO_TS_t?
AO_TS_t AO_locks[AO_HASH_SIZE] = {
^
atomic_ops.c:98:11: error: ?AO_TS_CLEAR? undeclared here (not in a function)
AO_TS_INITIALIZER, AO_TS_INITIALIZER, AO_TS_INITIALIZER, AO_TS_INITIALIZER,
^
atomic_ops.c:106:31: error: unknown type name ?AO_TS_t?
static void lock_ool(volatile AO_TS_t *l)
^atomic_ops.c: In function ?lock_ool?:
atomic_ops.c:110:3: warning: implicit declaration of function ?AO_test_and_set_acquire? [-Wimplicit-function-declaration]
while (AO_test_and_set_acquire(l) == AO_TS_SET)
^
atomic_ops.c:110:40: error: ?AO_TS_SET? undeclared (first use in this function)
while (AO_test_and_set_acquire(l) == AO_TS_SET)
^
atomic_ops.c:110:40: note: each undeclared identifier is reported only once for each function it appears in atomic_ops.c: At top level:
atomic_ops.c:114:36: error: unknown type name ?AO_TS_t?
AO_INLINE void lock(volatile AO_TS_t *l)
^
atomic_ops.c: In function ?lock?:
atomic_ops.c:116:54: error: ?AO_TS_SET? undeclared (first use in this function)
if (AO_EXPECT_FALSE(AO_test_and_set_acquire(l) == AO_TS_SET))
^
atomic_ops.c: At top level:
atomic_ops.c:120:38: error: unknown type name ?AO_TS_t?
AO_INLINE void unlock(volatile AO_TS_t *l)
^atomic_ops.c: In function ?unlock?:
atomic_ops.c:122:3: warning: implicit declaration of function ?AO_CLEAR? [-Wimplicit-function-declaration]
AO_CLEAR(l);
^atomic_ops.c: At top level:
atomic_ops.c:128:19: error: unknown type name ?AO_TS_t?
static volatile AO_TS_t init_lock = AO_TS_INITIALIZER;
^
atomic_ops.c: In function ?block_all_signals?:
atomic_ops.c:132:5: warning: implicit declaration of function ?AO_load_acquire? [-Wimplicit-function-declaration]
if (AO_EXPECT_FALSE(!AO_load_acquire(&initialized)))
^
atomic_ops.c:138:7: warning: implicit declaration of function ?AO_store_release? [-Wimplicit-function-declaration]
AO_store_release(&initialized, 1);
^atomic_ops.c: In function ?AO_fetch_compare_and_swap_emulation?:
atomic_ops.c:154:3: error: unknown type name ?AO_TS_t?
AO_TS_t *my_lock = AO_locks + AO_HASH(addr);
^atomic_ops.c: In function ?AO_compare_double_and_swap_double_emulation?:
atomic_ops.c:176:3: error: unknown type name ?AO_TS_t?
AO_TS_t *my_lock = AO_locks + AO_HASH(addr);
^atomic_ops.c: In function ?AO_store_full_emulation?:
atomic_ops.c:201:3: error: unknown type name ?AO_TS_t?
AO_TS_t *my_lock = AO_locks + AO_HASH(addr);
^atomic_ops.c: In function ?AO_spin?:
atomic_ops.c:223:3: warning: implicit declaration of function ?AO_load? [-Wimplicit-function-declaration]
AO_t j = AO_load(&spin_dummy);
atomic_ops.c:229:3: warning: implicit declaration of function ?AO_store? [-Wimplicit-function-declaration]
AO_store(&spin_dummy, j);
^
Makefile:597: recipe for target 'atomic_ops.lo' failed
make[3]: *** [atomic_ops.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
libtool: compile: /home/jviki/Projects/buildroot-mb/output/host/usr/bin/microblazeel-buildroot-linux-gnu-gcc -DHAVE_CONFIG_H -I../src -I../src -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -Wall -Wextra -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -c atomic_ops_stack.c -fPIC -DPIC -o .libs/atomic_ops_stack.o In file included from atomic_ops_stack.h:32:0,
from atomic_ops_malloc.h:29,
from atomic_ops_malloc.c:19:
atomic_ops.h:369:4: error: #error Cannot implement AO_compare_and_swap_full on this architecture.
# error Cannot implement AO_compare_and_swap_full on this architecture.
^
atomic_ops_malloc.c: In function ?AO_malloc_enable_mmap?:
atomic_ops_malloc.c:106:5: warning: implicit declaration of function ?AO_store? [-Wimplicit-function-declaration]
AO_store(&mmap_enabled, 1);
^
atomic_ops_malloc.c: In function ?get_chunk?:
atomic_ops_malloc.c:184:5: warning: implicit declaration of function ?AO_load? [-Wimplicit-function-declaration]
char *initial_ptr = (char *)AO_load(&initial_heap_ptr);
^
atomic_ops_malloc.c:191:9: warning: implicit declaration of function ?AO_compare_and_swap_acquire? [-Wimplicit-function-declaration]
(void)AO_compare_and_swap_acquire(&initial_heap_ptr,
^atomic_ops_malloc.c:197:5: warning: implicit declaration of function ?AO_compare_and_swap? [-Wimplicit-function-declaration]
if (AO_compare_and_swap(&initial_heap_ptr, (AO_t)my_chunk_ptr,
^
Makefile:597: recipe for target 'atomic_ops_malloc.lo' failed
make[3]: *** [atomic_ops_malloc.lo] Error 1
In file included from atomic_ops_stack.h:32:0,
from atomic_ops_stack.c:23:
atomic_ops.h:369:4: error: #error Cannot implement AO_compare_and_swap_full on this architecture.
# error Cannot implement AO_compare_and_swap_full on this architecture.
^Makefile:597: recipe for target 'atomic_ops_stack.lo' failed
make[3]: *** [atomic_ops_stack.lo] Error 1
make[3]: Leaving directory '/home/jviki/Projects/buildroot-mb/output/build/libatomic_ops-libatomic_ops-7_4_2/src' Makefile:456: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/jviki/Projects/buildroot-mb/output/build/libatomic_ops-libatomic_ops-7_4_2/src' Makefile:470: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/jviki/Projects/buildroot-mb/output/build/libatomic_ops-libatomic_ops-7_4_2' package/pkg-generic.mk:195: recipe for target '/home/jviki/Projects/buildroot-mb/output/build/libatomic_ops-libatomic_ops-7_4_2/.stamp_built' failed
make: *** [/home/jviki/Projects/buildroot-mb/output/build/libatomic_ops-libatomic_ops-7_4_2/.stamp_built] Error 2
Regards
Jan
On Wed, 27 Jan 2016 23:47:24 +0100
Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/[email protected]>
Quoted 188 lines · wrote:
Hello,
As many of you are aware, we have a number of build failures related to __sync_*() atomic operations, which we can't really solve properly today with our single
BR2_ARCH_HAS_ATOMICSboolean option.This patch series aims at reworking our atomic operation handling, by introducing four options:
BR2_TOOLCHAIN_HAS_SYNC_1,BR2_TOOLCHAIN_HAS_SYNC_2,BR2_TOOLCHAIN_HAS_SYNC_4,BR2_TOOLCHAIN_HAS_SYNC_8, to indicate which variants of atomic operations are available, depending on the architecture/toolchain. The full details are explained in PATCH 1.The overall direction of the series is:
- PATCH 1 introduces the
BR2_TOOLCHAIN_HAS_SYNC_xoptions, and has all the explanations about why we're doing this.- PATCH 2 updates the manual about the
BR2_TOOLCHAIN_HAS_SYNC_xoptions.- PATCH 3-12 aim at replacing the
BR2_ARCH_HAS_ATOMICSusage by the appropriateBR2_TOOLCHAIN_HAS_SYNC_xoptions. Note that in some cases,BR2_ARCH_HAS_ATOMICScan be removed completely.Along the way, we found that json-c was using some __sync_*() built-ins, so we added this dependency, which fixes some build failure.
- PATCH 13 removes the
BR2_ARCH_HAS_ATOMICSoption, which has become no longer used.- PATCH 14-17 use the new
BR2_TOOLCHAIN_HAS_SYNC_xoptions to fix numerous outstanding build failures related to atomic operations.Changes compared to v1:
- Drop patches that have been merged:
libftdi: C++ bindings need boost
libftdi: removeBR2_ARCH_HAS_ATOMICSdependency
icu: removeBR2_ARCH_HAS_ATOMICSdependency
openocd: removeBR2_ARCH_HAS_ATOMICSdependency- Fix numerous english typos in the commit log of "toolchain: add
BR2_TOOLCHAIN_HAS_SYNC_xhidden booleans" as well as in the patch itself. Following the review from Yann E. Morin.- Introduced a
BR2_TOOLCHAIN_X86_HAS_SYNC_8in "toolchain: addBR2_TOOLCHAIN_HAS_SYNC_xhidden booleans" to simplify the expression of the availability of 8-byte intrinsics on 32 bits x86. Suggested by Yann E. Morin.- In the documentation patch, remove a stray paragraph from a previous write-up documenting the new
BR2_TOOLCHAIN_HAS_SYNC_xoptions. Noticed by Yann E. Morin.- Fix minor typo and add Reviewed-by from Yann E. Morin on patch "json-c: needs
__sync_val_compare_and_swap_4".- Explicitly pass --disable-nonportable-atomics to the apr package configure script when no appropriate atomic
__syncfunctions are available. Suggested by Yann E. Morin.- Added Reviewed-by: "Yann E. MORIN" <[email protected]> on:
jack2: use the proper
BR2_TOOLCHAIN_HAS_SYNC_xsymbol
gauche: disable on SPARC(64), remove atomics dependency
msgpack: reworkBR2_ARCH_HAS_ATOMICSdependency- Added Tested-by/Acked from Yann E. Morin on:
libtorrent: use the proper
BR2_TOOLCHAIN_HAS_SYNC_xsymbols
thrift: removeBR2_ARCH_HAS_ATOMICSdependency- Added Acked-by: "Yann E. MORIN" <[email protected]> on
squid: rework atomic handling
arch: removeBR2_ARCH_HAS_ATOMICSoption
neard: add missingBR2_TOOLCHAIN_HAS_SYNC_4dependency
freerdp: add missingBR2_TOOLCHAIN_HAS_SYNC_4dependency
openal: add missingBR2_TOOLCHAIN_HAS_SYNC_4dependency- Fix a few typos in the commit log of "glog: fix atomic built-in problem" and added Reviewed-by from Yann E. Morin.
Those interested can also find this series in the Git branch at:
http://git.free-electrons.com/users/thomas-petazzoni/buildroot/log/?h=atomic-rework
Thanks in advance for your review and comments!
Thomas
Thomas Petazzoni (17):
toolchain: addBR2_TOOLCHAIN_HAS_SYNC_xhidden booleans docs/manual: document usage ofBR2_TOOLCHAIN_HAS_SYNC_x
json-c: needs__sync_val_compare_and_swap_4
pulseaudio: removeBR2_ARCH_HAS_ATOMICSdependency apache, apr: fix atomic handling
jack2: use the properBR2_TOOLCHAIN_HAS_SYNC_xsymbol
libtorrent: use the properBR2_TOOLCHAIN_HAS_SYNC_xsymbols
gauche: disable on SPARC(64), remove atomics dependency cairo, harfbuzz: rework atomic dependencies
squid: rework atomic handling
thrift: removeBR2_ARCH_HAS_ATOMICSdependency
msgpack: reworkBR2_ARCH_HAS_ATOMICSdependency
arch: removeBR2_ARCH_HAS_ATOMICSoption
glog: fix atomic built-in problem
openal: add missingBR2_TOOLCHAIN_HAS_SYNC_4dependency
freerdp: add missingBR2_TOOLCHAIN_HAS_SYNC_4dependency
neard: add missingBR2_TOOLCHAIN_HAS_SYNC_4dependencyarch/Config.in | 4 -- arch/Config.in.aarch64 | 3 -- arch/Config.in.arc | 3 -- arch/Config.in.arm | 3 -- arch/Config.in.bfin | 3 -- arch/Config.in.m68k | 3 -- arch/Config.in.microblaze | 3 -- arch/Config.in.mips | 3 -- arch/Config.in.nios2 | 3 -- arch/Config.in.powerpc | 3 -- arch/Config.in.sh | 3 -- arch/Config.in.x86 | 3 -- arch/Config.in.xtensa | 3 -- docs/manual/adding-packages-directory.txt | 11 +++-- package/apache/apache.mk | 4 -- package/apr/apr.mk | 15 ++++++ package/cairo/Config.in | 1 - package/cairo/cairo.mk | 6 +++ package/cairomm/Config.in | 2 - package/connman/Config.in | 1 + package/cwiid/Config.in | 2 +- package/directfb/Config.in | 5 +- package/efl/Config.in | 2 +- package/enlightenment/Config.in | 6 +-- package/espeak/Config.in | 2 +- package/fastd/Config.in | 1 + package/freerdp/Config.in | 2 + package/gauche/Config.in | 5 +- package/glog/glog.mk | 11 +++++ package/gstreamer/gst-plugins-bad/Config.in | 4 +- package/gstreamer/gst-plugins-base/Config.in | 4 +- package/gstreamer/gst-plugins-good/Config.in | 5 +- package/gstreamer1/gst1-plugins-bad/Config.in | 6 ++- package/gstreamer1/gst1-plugins-base/Config.in | 4 +- package/gstreamer1/gst1-plugins-good/Config.in | 5 +- package/gtkmm3/Config.in | 4 +- package/harfbuzz/Config.in | 2 + package/jack2/Config.in | 4 +- package/json-c/Config.in | 2 + package/libevas-generic-loaders/Config.in | 4 +- package/libfm/Config.in | 4 +- package/libgail/Config.in | 4 +- package/libgdiplus/Config.in | 2 - package/libgtk2/Config.in | 4 +- package/libgtk3/Config.in | 4 +- package/librsvg/Config.in | 4 +- package/libsvg-cairo/Config.in | 1 - package/libtorrent/Config.in | 4 +- package/mpd/Config.in | 6 ++- package/msgpack/Config.in | 4 +- package/neard/Config.in | 2 + package/openal/Config.in | 2 + package/openbox/Config.in | 4 +- package/opencv/Config.in | 2 +- package/opencv3/Config.in | 4 +- package/pango/Config.in | 4 +- package/pangomm/Config.in | 4 +- package/pcmanfm/Config.in | 4 +- package/pinentry/Config.in | 4 +- package/pulseaudio/Config.in | 4 +- package/pulseaudio/pulseaudio.mk | 7 ++- package/python-msgpack/Config.in | 4 +- package/rrdtool/Config.in | 2 +- package/rsyslog/Config.in | 2 + package/rtorrent/Config.in | 4 +- package/squid/squid.mk | 10 ++-- package/thrift/Config.in | 2 - package/ubus/Config.in | 1 + package/webkit/Config.in | 4 +- package/webkitgtk24/Config.in | 4 +- package/weston/Config.in | 4 +- package/xscreensaver/Config.in | 4 +- toolchain/toolchain-common.in | 65 ++++++++++++++++++++++++++ 73 files changed, 205 insertions(+), 139 deletions(-)
Signature · 4 lines
Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic
v2 cover Rework atomic handling
Jan,
Quoted 3 lines · Jan Viktorin
recently, I was doing some tests on MicroBlaze and discovered that I am missing the atomic operations there. Then I could see this patch series. Thanks for that, however, I have still issues with this.
Ah, so you're doing some Microblaze stuff? If so, some help would definitely be welcome to maintain this platform.
Quoted 1 line
The
libatomic_opsclaims to not support MicroBlaze in its Config.in.
Right.
Quoted 1 line
So it is not possible to use either __sync_* ones nor __atomic_* ones.
This has nothing to do with libatomic_ops or not.
__sync and __atomic built-ins are provided by gcc, the compiler.
They are completely orthogonal to libatomic_ops. Programs/libraries using __sync* or __atomic* functions do not need libatomic_ops.
Quoted 2 lines
Even if I change this and enable it for
BR2_microblaze, I am unable to compile thelibatomic_opsproperly (with the Buildroot toolchain 4.9.x).
There is no support for Microblaze in libatomic_ops, so this is not surprising. See src/atomic_ops/sysdeps/gcc/ in the libatomic_ops sources.
Maybe with generic.h / generic-small.h, libatomic_ops can rely on the __sync or __atomic built-ins, but I haven't tried this possibility.
Quoted 2 lines
Moreover, I've read somewhere that the new GCC connects the __sync_* interface to the __atomic_* interface internally. Is it true?
I don't know how things are implemented internally in gcc.
Quoted 3 lines
Is this done by the
libatomic_opslibrary? I am confused by this situation... I made some wrappers doing the __sync_* to __atomic_* translation but still with no success.
Are you use you are not confusing libatomic_ops and libatomic ?
libatomic_ops is a separate project, which has nothing to do with gcc.
libatomic is a library part of gcc, which exists since gcc 4.7, and provided as part of the gcc runtime on the target.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
v2 cover Rework atomic handling
Quoted 10 lines · On Mon, 1 Feb 2016 16:19:26 +0100 Thomas Petazzoni…
Jan,
Quoted 3 lines · Jan Viktorin
recently, I was doing some tests on MicroBlaze and discovered that I am missing the atomic operations there. Then I could see this patch series. Thanks for that, however, I have still issues with this.
Ah, so you're doing some Microblaze stuff? If so, some help would definitely be welcome to maintain this platform.
Unfortunately, this is just a single test on MicroBlaze after quite a long time. We've moved on to Zynq...
Quoted 33 lines
Quoted 2 lines
The
libatomic_opsclaims to not support MicroBlaze in its Config.in.Right.
Quoted 1 line
So it is not possible to use either __sync_* ones nor __atomic_* ones.
This has nothing to do with
libatomic_opsor not.
__syncand__atomicbuilt-ins are provided by gcc, the compiler.They are completely orthogonal to
libatomic_ops. Programs/libraries using __sync* or __atomic* functions do not needlibatomic_ops.Quoted 2 lines
Even if I change this and enable it for
BR2_microblaze, I am unable to compile thelibatomic_opsproperly (with the Buildroot toolchain 4.9.x).There is no support for Microblaze in
libatomic_ops, so this is not surprising. See src/atomic_ops/sysdeps/gcc/ in thelibatomic_opssources.Maybe with
generic.h/generic-small.h,libatomic_opscan rely on the__syncor__atomicbuilt-ins, but I haven't tried this possibility.Quoted 2 lines
Moreover, I've read somewhere that the new GCC connects the __sync_* interface to the __atomic_* interface internally. Is it true?
I don't know how things are implemented internally in gcc.
Quoted 3 lines
Is this done by the
libatomic_opslibrary? I am confused by this situation... I made some wrappers doing the __sync_* to __atomic_* translation but still with no success.
Quoted 6 lines
Are you use you are not confusing
libatomic_opsand libatomic ?
libatomic_opsis a separate project, which has nothing to do with gcc.libatomic is a library part of gcc, which exists since gcc 4.7, and provided as part of the gcc runtime on the target.
So, this the source of my confusion. Yes, I thought that libatomic and libatomic_ops are related or same as I couldn't find libatomic anywhere in the Buildroot. Thanks for clarification.
If I have a library that links with __atomic_* calls I just need to link with libatomic when building for MicroBlaze, is that correct?
Regards
Jan
Quoted 4 lines
Best regards,
Thomas
Signature · 4 lines
Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic
v2 cover Rework atomic handling
Dear Jan Viktorin,
Quoted 5 lines · Jan Viktorin
Quoted 2 lines
Ah, so you're doing some Microblaze stuff? If so, some help would definitely be welcome to maintain this platform.
Unfortunately, this is just a single test on MicroBlaze after quite a long time. We've moved on to Zynq...
Still you are our (only?) Microblaze user, so on you falls the responsibility of improving the Microblaze support :-)
Quoted 3 lines
So, this the source of my confusion. Yes, I thought that libatomic and
libatomic_opsare related or same as I couldn't find libatomic anywhere in the Buildroot. Thanks for clarification.
OK. However, still you have a point: it seems like libatomic_ops can use atomic built-ins from the compiler, so we should be able to enable its support on more architectures than what we have today.
Quoted 2 lines
If I have a library that links with __atomic_* calls I just need to link with libatomic when building for MicroBlaze, is that correct?
As long as you have >= gcc 4.7, you can link with -latomic and you'll get the __atomic built-ins. See my table in PATCH 1 of this series. For Microblaze, it says:
Microblaze - - Y - L L Y L 4.9
Which means that the __atomic functions for 4-byte types are built-in (no need for -latomic). However, for 1-byte, 2-byte and 8-byte types, -latomic is needed.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com