In file included from /usr/include/grpcpp/completion_queue.h:43: In file included from /usr/include/grpcpp/impl/codegen/sync.h:25: In file included from /usr/include/grpcpp/impl/sync.h:30: In file included from /usr/include/absl/synchronization/mutex.h:67: In file included from /usr/include/absl/base/const_init.h:25: In file included from /usr/include/absl/base/config.h:86: /usr/include/absl/base/policy_checks.h:79:2: error: "C++ versions less than C++14 are not supported." 79 | #error "C++ versions less than C++14 are not supported." | ^ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_llvm-20241010-060009 The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-13 * clang/llvm (if any): clang version 19.1.1+libcxx Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/19/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/19 19.1.1+libcxx Python 3.12.7 Available Ruby profiles: [1] ruby32 (with Rubygems) [2] ruby33 (with Rubygems) * Available Rust versions: [1] rust-bin-1.81.0 * The following VMs are available for generation-2: 1) Eclipse Temurin JDK 11.0.24_p8 [openjdk-bin-11] 2) Eclipse Temurin JDK 17.0.12_p7 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.4_p7 [openjdk-bin-21] 4) Eclipse Temurin JDK 8.422_p05 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 [2] openjdk-bin-11 [3] openjdk-bin-17 [4] openjdk-bin-21 system-vm The Glorious Glasgow Haskell Compilation System, version 9.2.8 php cli (if any): [1] php8.3 * go version go1.23.1 linux/amd64 HEAD of ::gentoo commit 2a58c05451fee793641ddd2dd4eea20256f139ac Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sun Oct 13 09:48:36 2024 +0000 2024-10-13 09:48:35 UTC emerge -qpvO =net-misc/frr-10.1.1 [ebuild N ] net-misc/frr-10.1.1 USE="grpc ospfapi pam -doc -fpm -nhrp -rpki -snmp -test" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11"
Created attachment 905594 [details] emerge-info.txt
Created attachment 905595 [details] emerge-history.txt
Created attachment 905596 [details] environment
Created attachment 905597 [details] etc.clang.tar.xz
Created attachment 905598 [details] etc.portage.tar.xz
Created attachment 905599 [details] logs.tar.xz
Created attachment 905600 [details] net-misc:frr-10.1.1:20241013-104814.log.xz
Created attachment 905601 [details] qlist-info.txt.xz
Created attachment 905602 [details] temp.tar.xz
Created attachment 905603 [details] var.tmp.clang.tar.xz
jkroon@plastiekpoot ~ $ equery belongs /usr/include/absl/base/policy_checks.h * Searching for /usr/include/absl/base/policy_checks.h ... dev-cpp/abseil-cpp-20240116.2-r4 (/usr/include/absl/base/policy_checks.h) So the error comes from abseil-cpp, but I have no idea how to sort this on frr side? #if __cplusplus < 201402L This seems to work correctly for gcc, but no llvm? I *suspect* that either: 1. LLVM doesn't export the appropriate #define's; or 2. abseil-cpp requires extra checks to correctly check for LLVM. What I *am* seeing in the abseil-cpp file is that no check is done unless __cplusplus is defined, so assuming llvm does define __cplusplus but not in a way expected by abseil-cpp.
As far as I understand, the problem is that grpc 1.65 which requires =dev-cpp/abseil-cpp-20240116 is not built with a version of the C++ standard lower than 23 (c++2b). I was able to build it by manually editing the Makefile: CXX = x86_64-pc-linux-gnu-g++ -std=gnu++23 CXXCPP = x86_64-pc-linux-gnu-g++ -E -std=gnu++23 I don't really understand yet how to solve this beautifully
Makefile should be edited after the configuration step: ebuild 1. ebuild frr-9.1.2.ebuild configure 2. edit /var/tmp/portage/net-misc/frr-9.1.2/work/frr-frr-9.1.2/Makefile 3. ebuild frr-9.1.2.ebuild merge
And will -std=gnu++23 work on say CC=clang? I do think the better options would be to pass GRPC_CFLAGS=-std=gnu++23 to emake. Which means src_compile can no longer simply call default. src_compile() { emake GRPC_CFLAGS=-std=gnu++23 use doc && emake -C doc html } Should thus do the trick. I'm however unable to reproduce the issue described here. If I set USE=grpc I get errors about being unable to cast from char* to int ... which is something different.
What does grpc have to do with it? You're not compiling grpc, but frr with abseil headers (which comes as a grpc dependency). It's abseil 20240116 that requires c++23.
Roughly speaking: The system has grpc 1.65 installed which requires abseil 20240116 frr requires grpc, grpc includes abseil headers (in this case version 20240116), this version requires c++23 for compilation
> And will -std=gnu++23 work on say CC=clang? no, there is another error, even on standard 23 In file included from lib/northbound_grpc.cpp:9: In file included from /usr/include/grpcpp/grpcpp.h:55: In file included from /usr/include/grpcpp/create_channel.h:25: In file included from /usr/include/grpcpp/security/credentials.h:30: In file included from /usr/include/grpcpp/security/tls_credentials_options.h:31: In file included from /usr/include/grpcpp/security/tls_crl_provider.h:22: In file included from /usr/include/grpc/grpc_crl_provider.h:25: In file included from /usr/include/absl/status/statusor.h:51: In file included from /usr/include/absl/status/internal/statusor_internal.h:24: In file included from /usr/include/absl/status/status.h:66: In file included from /usr/include/absl/status/internal/status_internal.h:27: In file included from /usr/include/absl/strings/cord.h:80: In file included from /usr/include/absl/crc/internal/crc_cord_state.h:23: /usr/include/absl/crc/crc32c.h:184:35: error: 'FormatSpecTemplate<void>' is unavailable: Format specified does not match the arguments passed. 184 | return os << absl::StreamFormat("%08x", static_cast<uint32_t>(crc)); | ^ /usr/include/absl/strings/internal/str_format/bind.h:141:3: note: 'FormatSpecTemplate<void>' has been explicitly marked unavailable here 141 | FormatSpecTemplate(const char* s) // NOLINT | ^
In general, despite the fact that the GRPC_CFLAGS variable is actually there, redefining it at the ebuild level does not help
(In reply to Alexander from comment #16) > Roughly speaking: > The system has grpc 1.65 installed which requires abseil 20240116 > > frr requires grpc, grpc includes abseil headers (in this case version > 20240116), this version requires c++23 for compilation And thus why amending GRPC_CFLAGS should do the trick.
@Alerig - assuming you're also compiling FRR with USE=-grpc? What does gRPC bring to the table for us here? From what I can tell there is currently no working way to compile FRR with USE=grpc, so my suggestion is to can it, and if we get user requests to bring it back put in the effort at that point?
I confirm, I never tried to use it
Looks like it provides a convenient mechanism for remote control, which would be useful for a looking glass or central management service. I suggest we kill it?
We can try yeah, worst case scenario someone complains in a bug report and then we’ll see how we can actually fix this bug.
I don't know, everything works for me) Why disable something that can be fixed, at least no one has time for it) This flag is already disabled by default > bgpd_options=" -A 127.0.0.1 -M grpc:9879" ospfd_options=" -A 127.0.0.1 -M grpc:9880" ss -nn6tlp | i 98 LISTEN 0 4096 *:9880 *:* users:(("ospfd",pid=93844,fd=20)) LISTEN 0 4096 *:9879 *:* users:(("bgpd",pid=93852,fd=27))
@Alarig - I think both of us missed that Alexander is using it. @Alexander - Just to be clear: You're able to build it specifically by manually editing the Makefile, and ONLY by doing that? [ebuild UD~] net-misc/frr-10.1.1:0/10.1::gentoo [10.2:0/10.2::gentoo] USE="grpc* pam -doc -fpm -nhrp -ospfapi -rpki -snmp -test" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11" 0 KiB Could you please provide the output of the following: x86_64-pc-linux-gnu-g++ -v The emerge --info from Toralf has: CXX="clang++" CXXFLAGS="-O2 -pipe -march=native -fno-diagnostics-color" So it's using clang ... will see if I can reproduce with that, in the meantime it looks like abseil 20240722.0 has been marked stable, and against that I'm getting a bunch of errors on ABSL_CHECK like: /usr/include/grpcpp/impl/call_op_set.h:981:7: error: invalid conversion from 'const char*' to 'int' [-fpermissive] 981 | ABSL_CHECK(false); | ^~~~~~~~~~ | | | const char* (The arguments to ABSL_CHECK doesn't seem to matter)
x86_64-pc-linux-gnu-g++ -v Using built-in specs. COLLECT_GCC=x86_64-pc-linux-gnu-g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/13/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-13.3.1_p20241115/work/gcc-13-20241115/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/13/python --enable-objc-gc --enable-languages=c,c++,d,objc,obj-c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 13.3.1_p20241115 p1' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-offload-defaulted --enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp --disable-libada --enable-cet --enable-systemtap --disable-valgrind-annotations --enable-vtable-verify --with-zstd --with-isl --disable-isl-version-check --enable-default-pie --enable-default-ssp --disable-fixincludes --with-build-config=bootstrap-cet Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.3.1 20241115 (Gentoo Hardened 13.3.1_p20241115 p1) > @Alexander - Just to be clear: You're able to build it specifically by manually editing the Makefile, and ONLY by doing that? Yep > x86_64-pc-linux-gnu-g++ -v I don't use clang by default
Created attachment 914593 [details] emerge --info
I looked at the scripts a little more, frr uses autoconf, and quite an old one as far as I understand. In configure.ac you can also specify AX_CXX_COMPILE_STDCXX([17], [ext]) and then CXX and СXXCPP in Makefile are set automatically and you don't need to change Makefile manually. But for standard 20 and higher, aclocal crashes at the configuration stage: Failed running 'aclocal'! Although it says here that it should support: https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html The script m4/ax_cxx_compile_stdcxx.m4 itself seems to have been taken from a version that only supported up to standard 17
Although based on this: https://github.com/gcc-mirror/gcc/blob/master/config/ax_cxx_compile_stdcxx.m4 there is basically no support for standard 20 and higher
Although no, everything is there) http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_cxx_compile_stdcxx.m4
If you replace the ax_cxx_compile_stdcxx.m4 script from the link above and use gcc14 (it is now available in portage) (the built-in variable __cplusplus is important, look like this: x86_64-pc-linux-gnu-g++ -dM -E -std=gnu++23 main.cpp | grep __cplusplus) and fix confugure.ac: AX_CXX_COMPILE_STDCXX([23], [ext]) Then everything is copied. If you use gcc13, the check does not work, since in that script (ax_cxx_compile_stdcxx.m4) the built-in variable __cplusplus is checked
> Then everything is copied * not copied , compile )
