Compilation error in cpp-driver-2.16.2 when using C++98 standard
Description
Environment
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-host-pie --enable-host-bind-now --enable-languages=c,c++,fortran,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-plugin --enable-initfini-array --without-isl --enable-multilib --with-linker-hash-style=gnu --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_64=x86-64-v2 --with-arch_32=x86-64 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.1 20221121 (Red Hat 11.3.1-4) (GCC)
Pull Requests
Activity
@piyush anand So I’ll begin by talking about our goals around C++ standards conformance. As of the in-progress release we make a best efforts attempt to conform to C++98 but there’s no explicit guarantee that we’ll always meet that standard. We don’t rigorously enforce that standard in the build and we certainly don’t guarantee it for third-party libs. I’m going to be sending a message to the mailing list shortly on this very point, specifically discussing the plans for upcoming releases so definitely keep an eye out for that.
That said, I’m happy to remove the non-C++98 usage in metrics.hpp. We added that code when working on https://datastax-oss.atlassian.net/browse/CPP-964 and I simply missed it’s impact on our support for C++98. That said there isn’t anything I can do about the uv.h case. That source is entirely within the control of libuv and their standards conformance is entirely managed by their project; I don’t know which libuv versions (if any) guarantee strict compat with C++98. If that’s a goal you’ll have to do some investigation and use a version which meets your needs.
We may be completely out of luck here. As part of work on https://datastax-oss.atlassian.net/browse/CPP-1000 I’ve tried to build using the cmake CXX_STANDARD variable. If this is set to “98” I get “--std=gnu++98” which leads to compilation issues well before we ever get to the metrics code:
[ 3%] Building CXX object src/CMakeFiles/cassandra.dir/abstract_data.cpp.o
cd /work/git/cpp-driver/build/src && /usr/bin/c++ -DCASS_BUILDING -Dcassandra_EXPORTS -I/work/git/cpp-driver/src/gssapi -I/work/git/cpp-driver/src/third_party/curl -I/work/git/cpp-driver/src/third_party/hdr_h
istogram -I/work/git/cpp-driver/src/third_party/http-parser -I/work/git/cpp-driver/src/third_party/minizip -I/work/git/cpp-driver/src/third_party/mt19937_64 -I/work/git/cpp-driver/src/third_party/rapidjson/ra
pidjson -I/work/git/cpp-driver/src/third_party/sparsehash/src -I/work/git/cpp-driver/include -I/work/git/cpp-driver/src -I/work/local/libuv-1.44.2/include -Wall -pedantic -Wextra -Wno-long-long -Wno-unused-pa
rameter -Wno-variadic-macros -Wno-unused-local-typedefs -Werror -fPIC -std=gnu++98 -MD -MT src/CMakeFiles/cassandra.dir/abstract_data.cpp.o -MF CMakeFiles/cassandra.dir/abstract_data.cpp.o.d -o CMakeFiles/cas
sandra.dir/abstract_data.cpp.o -c /work/git/cpp-driver/src/abstract_data.cpp
In file included from /work/git/cpp-driver/src/third_party/sparsehash/src/sparsehash/template_util.h:52,
from /work/git/cpp-driver/src/third_party/sparsehash/src/sparsehash/type_traits.h:63,
from /work/git/cpp-driver/src/third_party/sparsehash/src/sparsehash/internal/densehashtable.h:102, from /work/git/cpp-driver/src/third_party/sparsehash/src/sparsehash/dense_hash_set:108,
from /work/git/cpp-driver/src/dense_hash_set.hpp:22,
from /work/git/cpp-driver/src/address.hpp:22,
from /work/git/cpp-driver/src/serialization.hpp:20,
from /work/git/cpp-driver/src/buffer.hpp:21,
from /work/git/cpp-driver/src/abstract_data.hpp:21,
from /work/git/cpp-driver/src/abstract_data.cpp:17:
/work/git/cpp-driver/src/third_party/sparsehash/src/sparsehash/internal/sparseconfig.h:6:20: error: ‘hash’ in namespace ‘std’ does not name a template type
6 | #define HASH_NAME hash
| ^~~~
/work/git/cpp-driver/src/third_party/sparsehash/src/sparsehash/internal/sparseconfig.h:33:42: note: in expansion of macro ‘HASH_NAME’ 33 | #define SPARSEHASH_HASH HASH_NAMESPACE::HASH_NAME
| ^~~~~~~~~
/work/git/cpp-driver/src/third_party/sparsehash/src/sparsehash/dense_hash_set:114:27: note: in expansion of macro ‘SPARSEHASH_HASH’
114 | class HashFcn = SPARSEHASH_HASH<Value>, // defined in sparseconfig.h
| ^~~~~~~~~~~~~~~
/work/git/cpp-driver/src/third_party/sparsehash/src/sparsehash/internal/sparseconfig.h:4:25: note: ‘std::hash’ is only available from C++11 onwards
4 | #define HASH_NAMESPACE std
|
The included third-party spareshash lib requires C++11 and gets included (transitively) from abstract_data.cpp. Any explicit enforcement of the C++98 standard will completely fail to compile due to C++11 usage in the lib. There aren’t any macro conditionals around those includes… they’re all just direct includes from source.
Unsurprisingly I get an identical result if I manually add “--std=c++98” to the command line invocation instead… so this isn’t some weird gcc/GNU thing.
In short I think we already have significant C++98 compliance issues before we get to the new metrics code… which makes me wonder if the goal of pursuing C++98 conformance is even realistic.
To clarify my earlier comment: this issue (like CPP-1000) will be addressed in the upcoming 2.17.2 release. The work of actually bringing us back into conformance with C++98 will be handled on this ticket; https://datastax-oss.atlassian.net/browse/CPP-1000 will be aimed at making sure we have explicit test coverage against the minimum standard.
I don’t have a workaround at the moment but I’ll see if I can come up with something.
Thanks for reply.
But with new package 2.17.1, certain functionality are introduced in source code of cassandra cpp driver, which is available in C++11 standard only and gives compilation error with C++98 standard. eg when compiled using c++98 flag, gives following compilation error.
metrics.hpp:275:35: error: extended initializer lists only available with '-std=c++11' or '-std=gnu++11' [-Werror]
275 | , zero_snapshot_(Snapshot {0,0,0,0,0,0,0,0,0,0}) {
| ^
cc1plus: all warnings being treated as errors
Could you please help us provide workaround or any solution as I am not able to find any in ticket attached.
Note discussion around similar errors in https://datastax-oss.atlassian.net/browse/CPP-1000
Hello Team
I have downloaded the cassandra cpp driver cpp-driver-2.17.1 and followed instruction to build , but got following compilation error, using flag -std=c++98. It seems we have directly used C++11 features which is incompatible with c++98 flag.
Error1:
~/cppDriver/cpp-driver-2.17.1/src/metrics.hpp:276:35: error: extended initializer lists only available with '-std=c++11' or '-std=gnu++11' [-Werror]
276 | , zero_snapshot_(Snapshot {}) {
| ^
cc1plus: all warnings being treated as errors
Error 2:
~/cppDriver/cpp-driver-2.17.1/build/dependencies/lib/libuv/include/uv.h:618:23: error: comma at end of enumerator list [-Werror=pedantic]
618 | UV_TCP_REUSEPORT = 2,
| ^
~/cppDriver/cpp-driver-2.17.1/build/dependencies/lib/libuv/include/uv.h:1325:33: error: comma at end of enumerator list [-Werror=pedantic]
1325 | UV_THREAD_PRIORITY_LOWEST = -2,
| ^
cc1plus: all warnings being treated as errors
Could you please help providing resolution for same, as we have not faced such issue till now, and version 2.16.x reported with critical vulnerability, so we need to update cpp Cassandra driver.
Thanks