Optional C++ support depends on icu, the icu version bump to 59.1
brought ABI-breaking changes
http://site.icu-project.org/download/59#TOC-char16_t-in-C-
which are incompatible with beecrypt. Since beecrypt did not get any
updates upstream since 2009 and no package uses beecrypt's C++ support
we disable this broken option.
With C++ support removed patches 0002 & 0004 are not needed anymore.
Fixes
http://autobuild.buildroot.net/results/a1a/a1ad507371192ddecacab0df91f7b2a84c7c288d/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
According to the release notes "Compiler support for C++11 is now
required for building the ICU libraries.
GCC: version 4.8 and later has been tested."
Added corresponding dependencies and reverse dependencies.
Removed patch 0006 applied upstream.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The BR2_ARCH_HAS_ATOMICS was added because on ARC, atomic instructions
may not be provided by the architecture and therefore the compiler
does not provide the __sync_*() built-ins.
However, since then, icu was changed and is now able to use C++11
atomics, or even no atomic operations at all. In fact, icu will:
* If possible, it will use C++11 atomics, which internally rely on
the __atomic built-ins. These are available since gcc 4.7, and all
architectures provide it. On some architectures, you *must* link
with libatomic, on some other architectures, they are available
built-in, but in all cases, linking against libatomic does not
harm. Thanks to this, even ARC with no atomic support (which was
the original reason for adding the BR2_ARCH_HAS_ATOMICS) dependency
builds fine, provided -latomic is added to LIBS.
* If C++11 atomics are not available, then it falls back to
__sync_*() built-ins, which allows compilers older than 4.7 to be
supported.
* If really no atomic mechanism is available, then it falls back to a
basic implementation based on a mutex.
Conclusion:
- The BR2_ARCH_HAS_ATOMICS dependency is no longer needed.
- We need to link with -latomic when gcc >= 4.7 is used.
Note that reverse dependencies of icu are also changed accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
C++ support unconditionally needs shared libraries; it uses
dlopen/dlsym.
Also, fix the conditions under which the comment is shown.
Finally, explicitly require C++ support when configuring.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
And propagate to the reverse dependencies of icu.
Also, fix beecrypt's comment: only the C++ support needs atomics.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ICU requires GCC built-in atomic functions which are architecture specific
and may not be implemented.
Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
beecrypt used to pull in icu automatically when C++ support was enabled,
but since icu is pretty large and slow, that automatic dependency was
removed. However, it is not obvious to the user that he should enable
icu in order to get C++ support in beecrypt. Therefore, make the C++
support a user visible config option and mention icu in the help text.
It would also be possible to automatically enable C++ support if icu
happens to be selected for another reason, but that doesn't really seem
to offer an advantage.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Instead of automatically pulling in the (big) icu library if the toolchain
dependencies are available.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
icu does not recognize 'uclinux' as a supported platform. While making
it recognize uclinux is easy, there is another problem down the road:
icu does very weird things to generate an ELF library containing
static data (libicudata.a), and the generated library being ELF, it is
not compatible with the FLAT binary format expected by uclinux
platforms such as Blackfin in FLAT format.
Therefore, we simply disallow the selection of icu on FLAT
platforms.
Note that adding a dependency on BR2_BINFMT_ELF doesn't work, because
BR2_BINFMT_FDPIC is considered to be separate (even if technically
FDPIC is a derivative of ELF). That's why the dependency we're adding
is "depends on !BR2_BINFMT_FLAT" and not "depends on BR2_BINFMT_ELF".
Fixes:
http://autobuild.buildroot.org/results/b41/b415fed7fae4012bad7d8b53a481bd71bdab716f/build-end.log
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
icu depends on __sync_sub_and_fetch and other atomic primitives that
don't exist in the ARC toolchain yet.
[Peter: adjust beecrypt/php comment dependency, don't mention atomic builtins]
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch lines up the comments in Config.in files that clarify which
toolchain options the package depends on.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The issue with cppglue.cxx is still present in 4.2.1, but the previous
workaround had to be extended to allow builds with C++ support.
Similary, the ICU check didn't handle cross compilation.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
