As we discussed on the mailing list, using $(<pkg>_NAME) when defining
CPE ID variables feels a bit odd and needlessly complicated. Just use
the package name directly.
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* add option for new library Boost.JSON
* drop patch 0001 as it's applied upstream
* host: disable options that were added over time but never disabled for the host-build
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Not needed since commit 63332c33aa
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch adds CPE ID information for a significant number of
packages.
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since version 1.74.0, boost atomics needs a toolchain that always
supports lockfree atomic bytes so add dependendy on
BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS:
https://github.com/boostorg/atomic/issues/42
Fixes:
- http://autobuild.buildroot.org/results/c03a786791e3aa7801cf1bff9934c4a105f54ce1
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr:
- add the new dependency as its own 'depends on' line
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
nowide library has been added in version 1.73.0 and is enabled by
default
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
GCC 10 with -std=c++20 breaks boost library due to allocator changes.
https://github.com/boostorg/bimap/issues/23
We need boost 1.74.0 to fix build with gcc-10 -std=c++20. Note that none
of the Buildroot packages that use boost set -std=c++20, so no in-tree
failures.
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
Reviewed-by: Michael Nosthoff <buildroot@heine.tech>
Tested-by: Michael Nosthoff <buildroot@heine.tech> for arm
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
When building with Boost Build the CXXFLAGS are extended depending
on the optimization level set. When not defined explicitly the
optimization level depends on the <variant>. For release it's 'speed'
and for debug it's set to 'off'
These flags overwrite the -O flag passed in with TARGET_CXXFLAGS as
it is appended when calling g++.
This commit sets the Optimization flags generated by Boost Build
to the value of TARGET_OPTIMIZATION no matter what level is used.
As Boost Build offers no nice way to alter those values the gcc
toolchain file is altered directly.
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
First patch is not needed since version 1.67.0 and
90dd8146fb
Indeed, since this bump, the patch is wrongly patching
virtual string_type format(double value,size_t &code_points) const
instead of:
virtual string_type format(int64_t value,size_t &code_points) const
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This CVE does not affect the boost package, but is misclassified by our
CVS tracker. As per the advisory:
Unspecified vulnerability in Boost before 6.x-1.03, a module for
Drupal, allows remote attackers to create new webroot directories
via unknown attack vectors.
Ignore the CVS, and expand a comment to explain it.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: expand the comment]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
boost-thread needs std::current_exception since version 1.71.0 and
386f5507cb
std::current_exception depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_64735 as a
result, gnuradio fails to build on:
[ 12%] Building CXX object gnuradio-runtime/lib/pmt/CMakeFiles/gnuradio-pmt.dir/pmt_pool.cc.o
In file included from /home/test/autobuild/run/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/boost/exception/detail/exception_ptr.hpp:15:0,
from /home/test/autobuild/run/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/boost/exception_ptr.hpp:9,
from /home/test/autobuild/run/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/boost/thread/exceptional_ptr.hpp:10,
from /home/test/autobuild/run/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/boost/thread/future.hpp:34,
from /home/test/autobuild/run/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/boost/thread.hpp:24,
from /home/test/autobuild/run/instance-2/output-1/build/gnuradio-3.7.13.5/gnuradio-runtime/include/pmt/pmt_pool.h:27,
from /home/test/autobuild/run/instance-2/output-1/build/gnuradio-3.7.13.5/gnuradio-runtime/lib/pmt/pmt.cc:31:
/home/test/autobuild/run/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/boost/exception/diagnostic_information.hpp: In function 'std::string boost::current_exception_diagnostic_information(bool)':
/home/test/autobuild/run/instance-2/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/boost/exception/diagnostic_information.hpp:49:26: error: 'current_exception' is not a member of 'std'
else if (auto* p=std::current_exception().__cxa_exception_type())
^
So add this dependency on boost-thread, boost-log and gnuradio (the only
reverse dependencies of boost-thread that does not already depends on
!BR2_TOOLCHAIN_HAS_GCC_BUG_64735)
Finally, add this dependency on gqrx as it is a reverse dependency of
gnuradio
Fixes:
- http://autobuild.buildroot.org/results/c384205cf50929c320d90b620f2390837721d9f9
- http://autobuild.buildroot.org/results/47440354b336b943b74b72fa303b079dc962bfd0
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- Change BOOST_SITE to
https://dl.bintray.com/boostorg/release/1.71.0/source to get latest
boost version
- Update path of bjam
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The recent addition of a RISC-V musl toolchain uncovered an issue in
Boost's endianness detection. Boost endianness detection only works
for C libraries that pretend to be glibc *or* if the architecture is
explicitly handled by Boost endian.h header. Neither were true for
RISC-V musl, so we slightly patch boost to fix this problem.
Fixes:
http://autobuild.buildroot.net/results/a40b600a7d0fdb6a8a1ded7883b4936f120811f5/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The 0004-workaround-musl-bug.patch was added because musl's <sched.h>
was using memset(), but without including <string.h>. So including
just <sched.h> was causing a build failure.
However, this issue in musl has been fixed in upstream musl commit
48be5b6313d7b827acf555769e93b389fa9f6307 ("fix use of memset without
declaration in sched.h cpu set macros"). This commit was part of musl
1.1.17, which has been released a while ago. Both 2019.02.x, 2019.05.x
and master use a newer musl version.
So the workaround in Boost can be dropped.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
BR2_TOOLCHAIN_HAS_GCC_BUG_85180 dependency is already satisfied because
BR2_PACKAGE_BOOST_FIBER depends on
BR2_PACKAGE_BOOST_CONTEXT_ARCH_SUPPORTS that doesn't contain
BR2_microblaze and BR2_TOOLCHAIN_HAS_GCC_BUG_85180 depends right on
BR2_microblaze. So let's remove 'depends on
BR2_TOOLCHAIN_HAS_GCC_BUG_85180'.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since version 1.70.0, boost installs its own cmake files which are
utterly broken so don't install them otherwise all cmake packages using
boost (host-thrift, domoticz, i2pd ...) will fail because
BOOST_INCLUDE_DIRS will be empty
Fixes:
- http://autobuild.buildroot.org/results/4ada26bab5c1e6504c7d8c92672326ced1d336df
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- Remove fifth patch (already in version)
- Remove BR2_PACKAGE_BOOST_SIGNALS as signals is now removed. Its
removal was announced in 1.68 and its deprecation was announced in
1.54. Users are encouraged to use Signals2 instead.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit f3a483a81b added -std=c++11 to
boost build if context is selected and gcc is at least 4.7 however it
has the side effect that cc-tool fails to find boost_system with the
following error if context and system is enabled with a gcc greater
than 6:
configure:16312: /home/dawncrow/buildroot-test/scripts/instance-0/output/host/bin/x86_64-linux-g++ -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I/home/dawncrow/buildroot-test/scripts/instance-0/output/host/x86_64-buildroot-linux-musl/sysroot/usr/include -L/home/dawncrow/buildroot-test/scripts/instance-0/output/host/x86_64-buildroot-linux-musl/sysroot/usr/lib conftest.o -lboost_system -latomic >&5
conftest.o: In function `boost::system::error_category::std_category::equivalent(int, std::error_condition const&) const':
conftest.cpp:(.text._ZNK5boost6system14error_category12std_category10equivalentEiRKSt15error_condition[_ZNK5boost6system14error_category12std_category10equivalentEiRKSt15error_condition]+0x37): undefined reference to `boost::system::detail::generic_category_instance'
This error is related to the fact that since boost 1.68 and commit
7b6dcf6ac6,
boost system headers are now C++14 "by default" with gcc above 6:
- https://github.com/boostorg/system/issues/24
- https://github.com/boostorg/system/issues/26
- https://lists.boost.org/Archives/boost/2018/08/242770.php
So when building with gcc > 6, cc-tool thinks that boost has
generic_category_instance but because boost was compiled with
std=c++11, this function will not be in the library causing a link error
Instead of "hacking" even more boost, just remove -std=c++11 from
boost.mk and select BOOST_THREAD with gcc lower than 6
Fixes:
- http://autobuild.buildroot.org/results/fc8f8a64751c751b2b66301967cc008509bbaa70
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Tested-by: Matt Weber <matthew.weber@rockwellcollins.com>
Reviewed-by: Ferdinand van Aartsen <ferdinand@ombud.nl>
Tested-by: Ferdinand van Aartsen <ferdinand@ombud.nl>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Without std=c++11, mutex is not always correctly detected with gcc 4.7,
4.8 or even 5.x. As a result, boost_thread is wrongly selected by
boost_context.
mutex is available on gcc 4.7.x, the issue is that boost does not
correctly detect it because -std=c++11 was missing.
Keep thread select for gcc version lower or equal to 4.6. mutex is
available since gcc 4.4 (with std=c++0x) but common buildroot practice
for C++11 packages is to have a dependency on gcc 4.7, 4.8 or 4.9
depending on the requested C++11 features.
Fixes:
- http://autobuild.buildroot.net/results/fb046c04fe18bec973d120e4ab33971f32ba5769
- http://autobuild.buildroot.net/results/99f1a255b78a973faeb8bf3b94d78efc54426a8b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
boost-log builds fine with powerpc on uclibc nowadays so enable it back.
By removing this dependency, build failure on azmq is also fixed as this
package is currently selecting boost-log without fulfilling this
dependency
Fixes:
- http://autobuild.buildroot.net/results/9c373d0b5a1a59e2271d71c480d55a90a67b84cb
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
coroutine module does use chrono directly:
./libs/coroutine/performance/asymmetric/segmented/Jamfile.v2: <library>/boost/chrono//boost_chrono
./libs/coroutine/performance/asymmetric/Jamfile.v2: <library>/boost/chrono//boost_chrono
./libs/coroutine/performance/symmetric/segmented/Jamfile.v2: <library>/boost/chrono//boost_chrono
./libs/coroutine/performance/symmetric/Jamfile.v2: <library>/boost/chrono//boost_chrono
So put back select of chrono for coroutine
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
chrono is selected by thread (see libs/thread/build/Jamfile.v2):
rule usage-requirements ( properties * )
{
[...]
result += <library>/boost/chrono//boost_chrono ;
}
So add this select for BR2_PACKAGE_BOOST_THREAD and remove it from
BR2_PACKAGE_BOOST_COROUTINE, BR2_PACKAGE_BOOST_LOG,
BR2_PACKAGE_TYPE_ERASURE and BR2_PACKAGE_BOOST_WAVE
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As suggested by Arnout during the review of
http://patchwork.ozlabs.org/patch/934589, add a mechanism to detect a
missing boost select by checking that we do not install a boost library
which hasn't been selected by the user.
To manage a change of boost configuration by the user between two
builds, add a BOOST_PRE_INSTALL_TARGET_HOOKS to remove all boost
libraries before installing them.
Also, use ls with a wildcard instead of test to avoid trying to guess
library names if boost layout is set to tagged or versionned (the
wildcard will also help us to manage shared or static library)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The boost fiber module uses the boost context module, so it should
select it.
Due to this, the boost fiber module inherits the dependencies of boost
context: it needs exception_ptr handling, and is only available on the
architectures where boost context is supported.
Fixes:
http://autobuild.buildroot.net/results/56509d315defb95d4ac6e278a9d40cd98f61baa7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Thomas: use only one comment for both gcc bug dependencies.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
