Building fluxengine on Linux

[eburgdorf]

Hello,

I am attempting to build the fluxengine client on Linux (Ubuntu 24.04). Pre-reqs are installed. However, when I compile I receive the error:

lib/data/disk.cc:36:64: error: no member named 'to' in namespace 'std::ranges'
36 | std::views::keys(sectorsGroupedByTrack) | std::ranges::tostd::set())

clang and libc++-20-dev are both installed.

Are you able to help provide any clues as to what I'm missing?

Thanks
Erik

[VorpalBlade]

I think clang and fluxengine still builds against libstdc++ rather than libc++ by default. So check that you have the needed dev package for that installed as well.

Another possibility is that the version of libc++ or libstdc++ in 24.04 is too old for std::ranges::to. Fluxengine will always use the compiler named exactly clang, but Ubuntu has separate clang-19, clang-20 etc packages. The non-versioned name will be a symlink to the oldest of those on an LTS distro like 24.04. Editing the Makefiles to change CC to use clang-20 explicitly (and same for CXX to clang++-20) might help.

But I run Arch these days, so I can't test either of these suggestions. (Nor am I the developer of fluxengine, I just package it for Arch User Repository.)

[davidgiven]

I did some investigation here. It doesn't build with clang 17 on OSX, or on g++ 13 on Linux (the default used by the Github CI), but does build on g++ 15 on MSYS (also the default). However, manually building with clang 17 on my Fedora workstation does work, which points the finger at the libstdc++. It looks like clang will automagically find the gcc installation and use the libstdc++ from there, making using different versions of it tricky.

The reason for the new c++23 stuff is that ImHex uses it, so the overall C++ version for FluxEngine as a whole needs to be bumped. But this is so annoying that I'll look at removing the use of std::ranges::to. Ranges are much less useful than I thought they would be anyway (I swear, I am never using C++ for a big program ever again).

[VorpalBlade]

(I swear, I am never using C++ for a big program ever again).

May I interest you in Rust? For me it made programming fun again (I also used to code C++ and still do for my dayjob). Also, it has that "if it compiles it works" thing that the functional programming people were talking about for all those years. I find that code usually works on the first try, or has some simple logic bugs ("oops forgot to actually write out the result to a file").

That said, C++ <-> Rust FFI is currently less than ideal so I would be wary about introducing it into an existing project (but for greenfield: 100 %, even over python or other scripting languages).