- libabseil-cpp is now a dependency
- required c++ standard is now c++14 [0] --> requires gcc8
- drop fix for gcc <= 5 introduced in 25fd3b0a52
(c++ >= 14 is the default for gcc >= 8)
- update gcc required for depending packages qt5webengine & grpc
[0] 7c2552dd54
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
abseil and other google tools are now subject to
"Google's Foundational C++ Support Policy" [0][1]. This currently mandates
gcc 7.3.1 and C++14 as minimum versions.
Since we don't have guards for patch versions of gcc 7 use gcc 8 as minimum.
[0] https://github.com/abseil/abseil-cpp/releases/tag/20230125.0
[1] b842c39db8/foundational-cxx-support-matrix.md
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
drop cross-compile patch which is now upstream (again).
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- rework host-grpc-only-cpp-plugin.patch to match changed CMakeLists.txt
- reintroduce patch to fix cross_compile with host grpc_cpp_plugin [1]
- add patch to disable unconditionally downloading repos of 3rd party APIs not
used in build [2]
[1] https://github.com/grpc/grpc/pull/30378
[2] https://github.com/grpc/grpc/issues/30385
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fix the following build failure raised on uclibc and musl since the
reintroduction of the package in commit
16ff948444:
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-uclibcgnueabi/10.3.0/../../../../arm-buildroot-linux-uclibcgnueabi/bin/ld: /home/buildroot/autobuild/instance-1/output-1/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libabsl_stacktrace.so.2111.0.0: undefined reference to `backtrace'
Fixes:
- http://autobuild.buildroot.org/results/63ab2bc86cad03d5258492b17d1707078761d9b3
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Fix the following build failure raised since the addition of fourth
patch in commit 8251d8c255:
1 out of 22 hunks FAILED -- saving rejects to file CMakeLists.txt.rej
Fixes:
- http://autobuild.buildroot.org/results/44f6d7c61316e90d22e75cb1fb77c3bc5b31ad66
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, grpc depends on the full host-grpc, which in turn depends on host
versions of many other libraries. One of these, host-libabseil-cpp, also
requires a host gcc 4.9 or larger, a dependency which is not met on CentOS
7.
But in fact, the target grpc only needs the 'grpc_cpp_plugin' binary from
host-grpc. And that binary does not depend on host-libabseil-cpp or other
libraries, only on host-protobuf.
Given the above, simplify the grpc/host-grpc situation.
- Add a patch to the (host-)grpc CMakeLists.txt file to add an option to
only build grpc_cpp_plugin.
- Update grpc.mk and Config.in to remove the unnecessary dependencies, and
change the host-grpc configure options to make cmake happy.
The advantages of these changes are:
- making grpc available to older hosts with gcc < 4.8, like CentOS 7
- significantly reducing the build time of host-grpc and its dependencies
The patch was proposed upstream but not accepted with below rationale.
Perhaps input from others can help in persuading upstream in a future
attempt.
'What you're doing sounds like quite a narrow use case. But we simply
cannot provide a cmake option for every possible scenario in the world.
Introducing a new cmake option isn't for free and requires careful
design and maintenance.'
Nevertheless, given the benefits in terms of build time and dependency
reduction, it makes sense to apply this patch in spite of the disadvantage
of a local non-upstreamed patch.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Arnout: propagate removed dependency to collectd]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* update patch 0001 to match changed target code
* BSD-3c and MPL-2.0 licenses were added to LICENSE
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Some of the third party code is BSD-licensed. In addition, the roots.pem
certificate store is MPL-licensed.
This was probably already the case in earlier versions as well, but it
was only noticed while updating to 1.42.0 because the LICENSE file was
adapted for it.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* drop CMakeLists.txt patch applied upstream.
* Update patch for wrap_memcpy.cc to match changed target file.
* update patch numbering.
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes from Changelog [0]:
- Fix#25897 to avoid crashes when certificates are not yet updated
- [Backport] Fix use-after-unref bug in fault_injection_filter.
[0] https://github.com/grpc/grpc/releases/tag/v1.37.1
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
grpc has plugins for multiple programming languages, which are needed on
development machines only. Examples are grpc_cpp_plugin, grpc_ruby_plugin,
etc.
Even though before commit fedf3318e3,
grpc_cpp_plugin was not installed for target, all other plugins still were.
This causes additional build time and rootfs space.
As Buildroot does not support building a development environment for target,
these tools can be disabled.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In commit fedf3318e3, an obsolete patch to
support cross-compilation was removed, in favor of the upstream solution.
However, this caused a small change in behavior: for the target grpc, the
tool 'grpc_cpp_plugin' is now also built, while before it was not.
This tool is only really needed on development machines. Since Buildroot
does not support compilers and such on target itself, the tool is not
needed.
There exists an option gRPC_BUILD_GRPC_CPP_PLUGIN which can be set to 'OFF',
but disabling it in a cross-compilation context yields build failures.
Add a patch to fix that. This patch is intended to be upstreamed to grpc.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When cross-compiling grpc, a native tool 'grpc_cpp_plugin' is needed.
Patch '0001-target-build-using-host-plugin.patch' in Buildroot provides a
way to pass the path to this tool via a configure option
'gRPC_NATIVE_CPP_PLUGIN'.
In version 1.20.0, the upstream grpc project added better support for
cross-compiling via commit 0d7a0ded [1], searching for the native
grpc_cpp_plugin via PATH (rather than specifying it as configure option as
our patch was doing).
This change renders the mentioned Buildroot patch obsolete, so remove it.
[1] 0d7a0ded1c
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Michael Nosthoff <buildroot@heine.tech>
Tested-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Due to libabseil dependencies the host gcc is at least 4.9.
So the fix for host gcc 4.8 is no longer needed.
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
abseil depends on gcc >= 4.9 according to [0] and actually doesn't
compile anymore with the latest version bump.
This didn't show in the autobuilders as the C++11 issue fixed in the
previous commit shadowed it.
also update dependency in package/grpc.
fixes:
https://github.com/abseil/abseil-cpp/issues/795
[0] https://abseil.io/docs/cpp/platforms/platforms#linux
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- order dependencies alphabetically
- update hash
- alter patch offsets
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
re2 unconditionally uses -pthread and add it to re2.pc
Moreover, it fails to buid without threads on:
In file included from /home/peko/autobuild/instance-0/output-1/per-package/re2/host/opt/ext-toolchain/arm-buildroot-linux-uclibcgnueabihf/include/c++/8.3.0/arm-buildroot-linux-uclibcgnueabihf/bits/os_defines.h:39,
from /home/peko/autobuild/instance-0/output-1/per-package/re2/host/opt/ext-toolchain/arm-buildroot-linux-uclibcgnueabihf/include/c++/8.3.0/arm-buildroot-linux-uclibcgnueabihf/bits/c++config.h:508,
from /home/peko/autobuild/instance-0/output-1/per-package/re2/host/opt/ext-toolchain/arm-buildroot-linux-uclibcgnueabihf/include/c++/8.3.0/bits/stl_algobase.h:59,
from /home/peko/autobuild/instance-0/output-1/per-package/re2/host/opt/ext-toolchain/arm-buildroot-linux-uclibcgnueabihf/include/c++/8.3.0/memory:62,
from /home/peko/autobuild/instance-0/output-1/build/re2-2020-08-01/re2/filtered_re2.h:24,
from /home/peko/autobuild/instance-0/output-1/build/re2-2020-08-01/re2/filtered_re2.cc:5:
/home/peko/autobuild/instance-0/output-1/per-package/re2/host/arm-buildroot-linux-uclibcgnueabihf/sysroot/usr/include/features.h:218:5: warning: #warning requested reentrant code, but thread support was disabled [-Wcpp]
# warning requested reentrant code, but thread support was disabled
^~~~~~~
In file included from /home/peko/autobuild/instance-0/output-1/build/re2-2020-08-01/re2/prog.h:22,
from /home/peko/autobuild/instance-0/output-1/build/re2-2020-08-01/re2/bitstate.cc:28:
/home/peko/autobuild/instance-0/output-1/build/re2-2020-08-01/re2/re2.h:768:16: error: 'once_flag' in namespace 'std' does not name a type
mutable std::once_flag rprog_once_;
^~~~~~~~~
/home/peko/autobuild/instance-0/output-1/build/re2-2020-08-01/re2/re2.h:768:11: note: 'std::once_flag' is defined in header '<mutex>'; did you forget to '#include <mutex>'?
/home/peko/autobuild/instance-0/output-1/build/re2-2020-08-01/re2/re2.h:218:1:
+#include <mutex>
Fixes:
- http://autobuild.buildroot.org/results/7d7c6dcac3cb8ea6deb753178e85eb1c5c74c8e3
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Related changes:
- add dependency on Google RE2 package
- update patches to new offsets
Tested on Ubuntu 20.04
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The libabseil-cpp package fails to build on a number of CPU
architectures in our autobuilders.
On most CPU architectures, the first issue looked like this:
libabseil-cpp-20200225/absl/base/internal/direct_mmap.h: In function 'void* absl::lts_2020_02_25::base_internal::DirectMmap(void*, size_t, int, int, int, off64_t)':
libabseil-cpp-20200225/absl/base/internal/direct_mmap.h:121:39: error: static assertion failed: Platform is not 64-bit
121 | static_assert(sizeof(unsigned long) == 8, "Platform is not 64-bit");
| ~~~~~~~~~~~~~~~~~~~~~~^~~~
libabseil-cpp-20200225/absl/base/internal/direct_mmap.h:123:15: error: 'SYS_mmap' was not declared in this scope; did you mean 'SYS_mmap2'?
123 | syscall(SYS_mmap, start, length, prot, flags, fd, offset));
| ^~~~~~~~
| SYS_mmap2
Indeed, on 32-bit architectures, libabseil-cpp has some special code
to use the mmap2() system call, and it white-lists the supported
architectures. It is therefore trivial to add support for more
architectures.
However, once this is fixed, another issue arises:
absl/debugging/internal/examine_stack.cc uses the ucontext data
structures, which are not provided by uClibc-ng on all CPU
architectures, and even the code of libabseil-cpp does not exist for
all CPU architectures.
So, this commit solves that by simply making libabseil-cpp available
on architectures/C libraries where it is supported: it needs ucontext
support in the toolchain + a CPU architecture where
absl/debugging/internal/examine_stack.cc has the appropriate logic.
This new dependency is propagated to the reverse dependencies of
libabseil-cpp.
With this commit, libabseil-cpp passes a test-pkg -a test (so all
external toolchains used by the autobuilders):
andes-nds32 [ 1/45]: SKIPPED
arm-aarch64 [ 2/45]: OK
br-aarch64-glibc [ 3/45]: OK
br-arcle-hs38 [ 4/45]: SKIPPED
br-arm-basic [ 5/45]: SKIPPED
br-arm-cortex-a9-glibc [ 6/45]: OK
br-arm-cortex-a9-musl [ 7/45]: OK
br-arm-cortex-m4-full [ 8/45]: SKIPPED
br-arm-full [ 9/45]: OK
br-arm-full-nothread [10/45]: SKIPPED
br-arm-full-static [11/45]: SKIPPED
br-i386-pentium4-full [12/45]: OK
br-i386-pentium-mmx-musl [13/45]: OK
br-m68k-5208-full [14/45]: SKIPPED
br-m68k-68040-full [15/45]: SKIPPED
br-microblazeel-full [16/45]: SKIPPED
br-mips32r6-el-hf-glibc [17/45]: OK
br-mips64-n64-full [18/45]: OK
br-mips64r6-el-hf-glibc [19/45]: OK
br-mipsel-o32-full [20/45]: OK
br-nios2-glibc [21/45]: SKIPPED
br-openrisc-uclibc [22/45]: SKIPPED
br-powerpc-603e-basic-cpp [23/45]: SKIPPED
br-powerpc64le-power8-glibc [24/45]: OK
br-powerpc64-power7-glibc [25/45]: OK
br-powerpc-e500mc-full [26/45]: SKIPPED
br-riscv32 [27/45]: OK
br-riscv64 [28/45]: OK
br-riscv64-musl [29/45]: OK
br-sh4-full [30/45]: SKIPPED
br-sparc64-glibc [31/45]: SKIPPED
br-sparc-uclibc [32/45]: SKIPPED
br-x86-64-core2-full [33/45]: OK
br-x86-64-musl [34/45]: OK
br-xtensa-full [35/45]: SKIPPED
linaro-aarch64-be [36/45]: OK
linaro-aarch64 [37/45]: OK
linaro-arm [38/45]: OK
sourcery-arm-armv4t [39/45]: OK
sourcery-arm [40/45]: OK
sourcery-arm-thumb2 [41/45]: OK
sourcery-mips64 [42/45]: OK
sourcery-mips [43/45]: OK
sourcery-nios2 [44/45]: SKIPPED
sourcery-x86-64 [45/45]: OK
45 builds, 18 skipped, 0 build failed, 0 legal-info failed
Fixes:
http://autobuild.buildroot.net/results/ead663b4b67b0b57ed003a46db3182d95cc01bc0/
(and many similar build failures)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The libabseil-cpp build needs <dlfcn.h>, so let's add a
!BR2_STATIC_LIBS dependency. The only package which is selecting
libabseil-cpp, grpc, already had this dependency anyway.
Fixes:
http://autobuild.buildroot.net/results/2d796dd4cc43388da235b83f53778d902f477799/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Other changes:
- Add a dependency on libabseil-cpp
- Update the patches to apply properly.
Tested with the following distributions:
- Debian 9
- CentOS 7
- Fedora 32
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Other changes:
- Remove upstream patch 0004-Fix-gettid-naming-conflict.patch
- Remove upstream patch 0005-Rename-gettid-functions.patch
- Add a check for BR2_TOOLCHAIN_GCC_AT_LEAST_5 in grpc.mk. If the
selected toolchain is not at least version 5 or higher and the
optimization level is -Os, set the GRPC_CFLAGS and GRPC_CXXFLAGS
optimizations to -O2. This check prevents the following error:
error: failure memory model cannot be stronger than success memory model for '__atomic_compare_exchange'
Tested with test-pkg, all tests passed:
br-arm-full [1/6]: OK
br-arm-cortex-a9-glibc [2/6]: OK
br-arm-cortex-m4-full [3/6]: SKIPPED
br-x86-64-musl [4/6]: OK
br-arm-full-static [5/6]: SKIPPED
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
With Microblaze Gcc version < 8.x the build hangs due to gcc bug
85180: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180. The bug
shows up when building grpc with optimization but not when building
with -O0. To work around this, if BR2_TOOLCHAIN_HAS_GCC_BUG_85180=y we
force using -O0. Doing this let's optimize already present
CFLAGS/CXXFLAGS tweaking by introducing GRPC_CFLAGS and GRPC_CXXFLAGS
variable.
Fixes:
http://autobuild.buildroot.net/results/6f3/6f301904002cdd50dc3a66fe782b04a05b116319/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
... so we can drop all config options about it and previous versions.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On Github, a large number of projects name their tag vXYZ (i.e v3.0,
v0.1, etc.). In some packages we do:
<pkg>_VERSION = v0.3
<pkg>_SITE = $(call github foo,bar,$(<pkg>_VERSION))
And in some other packages we do:
<pkg>_VERSION = 0.3
<pkg>_SITE = $(call github foo,bar,v$(<pkg>_VERSION))
I.e in one case we consider the version to be v0.3, in the other case
we consider 0.3 to be the version.
The problem with v0.3 is that when used in conjunction with
release-monitoring.org, it doesn't work very well, because
release-monitoring.org has the concept of "version prefix" and using
that they drop the "v" prefix for the version.
Therefore, a number of packages in Buildroot have a version that
doesn't match with release-monitoring.org because Buildroot has 'v0.3'
and release-monitoring.org has '0.3'.
Since really the version number of 0.3, is makes sense to update our
packages to drop this 'v'.
This commit only addresses the (common) case of github packages where
the prefix is simply 'v'. Other cases will be handled by separate
commits. Also, there are a few cases that couldn't be handled
mechanically that aren't covered by this commit.
Signed-off-by: Victor Huesca <victor.huesca@bootlin.com>
[Arnout: don't change flatbuffers, json-for-modern-cpp, libpagekite,
python-scapy3k, softether]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
