Skip to content

clickhouse-cpp/2.5.1 Conan package fails to build with GCC 11 #452

@simsicon

Description

@simsicon

Summary

After the recent ConanCenter update of the clickhouse-cpp/2.5.1 recipe (as shown on the ConanCenter page, last updated 2025‑11‑17), building clickhouse-cpp/2.5.1 from source via Conan fails with GCC 11 and C++20.

The main error is:

  • use of std::memory_order::memory_order_relaxed instead of std::memory_order_relaxed in types.cpp

Additionally, there is another build failure due to a deprecated enum‑enum bitwise operation being treated as an error (-Werror).

Downgrading to clickhouse-cpp/2.5.0 makes the issue disappear, so this seems to be a regression in the 2.5.1 Conan recipe / sources.

———

Environment

  • OS: Linux x86_64
  • Compiler: GCC 11
  • C++ standard: gnu20 (profile compiler.cppstd=gnu20)
  • Conan client: 2.x (using conancenter remote)
  • Package: clickhouse-cpp/2.5.1 from ConanCenter
  • Consumer project uses:
    • conanfile.py with self.requires("clickhouse-cpp/2.5.1")
    • Profile sets compiler.libcxx=libstdc++11, build_type=Release

———

Conan profile (relevant parts)

[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.version=11
compiler.cppstd=gnu20
compiler.libcxx=libstdc++11
os=Linux

———

Steps to reproduce

  1. Create a minimal conanfile.py:

    from conan import ConanFile

    class TestClickhouseCpp(ConanFile):
    settings = "os", "compiler", "build_type", "arch"
    generators = "CMakeDeps", "CMakeToolchain"

    def requirements(self):
        self.requires("clickhouse-cpp/2.5.1")
    
  2. Run:

    conan install . --output-folder=build/conan_files --build=missing

  3. Let Conan download and build clickhouse-cpp/2.5.1 from ConanCenter.

———

Actual behavior

The build fails in the clickhouse-cpp sources.

Key errors (paths are Conan’s build folder):

/home//.conan2/p/b/click6c1a182889a69/b/src/clickhouse/types/types.cpp: In member function ‘uint64_t clickhouse::Type::GetTypeUniqueId() const’:
/home//.conan2/p/b/click6c1a182889a69/b/src/clickhouse/types/types.cpp:164:57: error: ‘memory_order_relaxed’ is not a member of ‘std::memory_order’
164 | if (type_unique_id_.load(std::memory_order::memory_order_relaxed) == 0) {
| ^~~~~~~~~~~~~~~~~~~~
/home//.conan2/p/b/click6c1a182889a69/b/src/clickhouse/types/types.cpp:166:112: error: ‘memory_order_relaxed’ is not a member of ‘std::memory_order’
166 | type_unique_id_.store(CityHash64WithSeed(name.c_str(), name.size(), code_), std::memory_order::memory_order_relaxed);
| ^~~~~~~~~~~~~~~~~~~~

From the same build, another error:

/home//.conan2/p/b/click6c1a182889a69/b/src/clickhouse/columns/lowcardinality.cpp: In member function ‘virtual void clickhouse::ColumnLowCardinality::SaveBody(clickhouse::OutputStream*)’:
/home//.conan2/p/b/click6c1a182889a69/b/src/clickhouse/columns/lowcardinality.cpp:344:88: error: bitwise operation between different enumeration types ‘{anonymous}::IndexType’ and ‘{anonymous}::IndexFlag’ is deprecated [-Werror=deprecated-enum-
enum-conversion]
344 | const uint64_t index_serialization_type = indexTypeFromIndexColumn(*index_column_) | IndexFlag::HasAdditionalKeysBit;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[2]: *** [clickhouse/CMakeFiles/clickhouse-cpp-lib.dir/columns/lowcardinality.cpp.o] Error 1

Full CMake/Make invocation is driven by Conan; the key point is that warnings are treated as errors and the deprecated enum‑enum bitwise OR becomes a hard error.

———

Expected behavior

  • clickhouse-cpp/2.5.1 builds successfully with GCC 11 and C++20 (and typical -Werror settings) via ConanCenter.
  • No misuse of std::memory_order.

———

Analysis

  1. Invalid use of std::memory_order

    In src/clickhouse/types/types.cpp the code currently uses:

    if (type_unique_id_.load(std::memory_order::memory_order_relaxed) == 0) {
    const auto name = GetName();
    type_unique_id_.store(
    CityHash64WithSeed(name.c_str(), name.size(), code_),
    std::memory_order::memory_order_relaxed
    );
    }

    But in standard C++ (since C++11):

    • std::memory_order is the enum type.
    • Enumerators are std::memory_order_relaxed, std::memory_order_acquire, etc., in namespace std, not as nested names inside the enum.

    The correct usage should be:

    if (type_unique_id_.load(std::memory_order_relaxed) == 0) {
    const auto name = GetName();
    type_unique_id_.store(
    CityHash64WithSeed(name.c_str(), name.size(), code_),
    std::memory_order_relaxed
    );
    }

    With this change, GCC 11 accepts the code.

  2. Deprecated enum bitwise OR with -Werror

    In src/clickhouse/columns/lowcardinality.cpp:

    const uint64_t index_serialization_type =
    indexTypeFromIndexColumn(*index_column_) | IndexFlag::HasAdditionalKeysBit;

    indexTypeFromIndexColumn returns an IndexType, and IndexFlag is a different enum. GCC 11 (with C++20 and current warning settings) warns:

    bitwise operation between different enumeration types … is deprecated

    Because warnings are treated as errors, this stops the build. One way to avoid this is to explicitly cast to an integer type before the bitwise operation, for example:

    const uint64_t index_serialization_type =
    static_cast<uint64_t>(indexTypeFromIndexColumn(*index_column_)) |
    static_cast<uint64_t>(IndexFlag::HasAdditionalKeysBit);

———

Workaround

As a temporary workaround on the consumer side, downgrading to clickhouse-cpp/2.5.0 in conanfile.py:

self.requires("clickhouse-cpp/2.5.0")

allows conan install ... to complete successfully in the same environment.

———

Request

  • Please fix the std::memory_order::memory_order_relaxed usage to std::memory_order_relaxed in types.cpp.
  • Please also consider adjusting the enum bitwise operation in lowcardinality.cpp (or relaxing the relevant warning) so that the library builds cleanly with modern compilers and -Werror.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions