[Bug] Build failure on Fedora 44 (GCC 16)

[cphlipot]

Git commit

$ git rev-parse HEAD
3d6064b

Operating System & Version

Fedora 44

GGML backends

Vulkan

Command-line arguments used

N/A (project did not build)

Steps to reproduce

attempt build on Fedora 44 using instructions in build.md

mkdir build && cd build
cmake .. -DSD_VULKAN=ON
cmake --build . --config Release

What you expected to happen

project gets built successfully.

What actually happened

build failed

Logs / error messages / stack trace

error: no match for 'operator=' (operand types are 'std::string' and 'std::u8string')
  267 | lora_entry.name = p.stem().u8string();

Additional context / environment details

Fedora 44 Ships with GCC 16. GCC 16 will compile projects with C++20 by default unless the project overides the behavior which stable-diffusion.cpp does not.

https://gcc.gnu.org/gcc-16/changes.html#cxx

C++20 by default: GCC 16 changes the default language version for C++ compilation from -std=gnu++17 to -std=gnu++20.

in C++20 it does not allow direct assignment from std::u8string to std::string, which stable diffusion cpp currently does and results in compiler errors.

potential fixes include:

1. use std::string instead of u8string
2. convert project to use u8string instead of std::string
3. compile with --std=c++17 to get old compiler behavior with the newer GCC so we don't need to change the source code.

see also https://stackoverflow.com/questions/56833000/c20-with-u8-char8-t-and-stdstring

[wbruna]

unless the project overides the behavior which stable-diffusion.cpp does not.

Actually, we do:

https://github.com/leejet/stable-diffusion.cpp/blob/master-593-3d6064b/CMakeLists.txt#L256
https://github.com/leejet/stable-diffusion.cpp/blob/master-593-3d6064b/examples/cli/CMakeLists.txt#L20
https://github.com/leejet/stable-diffusion.cpp/blob/master-593-3d6064b/examples/server/CMakeLists.txt#L104

target_compile_features(${TARGET} PUBLIC c_std_11 cxx_std_17)

And if I change that to C++20, I can reproduce that exact failure:

./examples/server/runtime.cpp: In function ‘void refresh_lora_cache(ServerRuntime&)’:
./examples/server/runtime.cpp:267:53: error: no match for ‘operator=’ (operand types are ‘std::string’ {aka ‘std::__cxx11::basic_string<char>’} and ‘std::u8string’ {aka ‘std::__cxx11::basic_string<char8_t>’})
  267 |             lora_entry.name     = p.stem().u8string();
      |    

so it's definitely active for our build targets.

[silvertuanzi]

Only set target_compile_features(${TARGET} PUBLIC c_std_11 cxx_std_17) isn't enough.

In my archlinux I use a mix compiler:
CC: gcc-16
CXX: g++-16
CUDA: nvcc13.2 with host g++-15

Build will failed with default cmake .. -G Ninja -DSD_CUDA=ON
But cmake .. -G Ninja -DSD_CUDA=ON -DCMAKE_CXX_STANDARD=17 build successfully.

I use the same commit 3d6064b

[cphlipot]

target_compile_features(${TARGET} PUBLIC c_std_11 cxx_std_17)

@wbruna Thanks for pointing to that. Based on my research and testing it looks like requesting a C++ feature set via target_compile_features() only guarantees a MINIMUM C++ version, not an EXACT C++ version. Since CMake assumes the GCC16 default C++20 already includes the features from C++17, it does not actually set -std=C++17 explicitly and just uses the default C++20 which causes issues with this project.

there is a bit more to read on that topic here: https://discourse.cmake.org/t/determining-the-compiler-default-c-standard/10389/7

The cxx_std_## features are for minimum standard levels. CXX_STANDARD will be honored even if it is lower than the compiler’s default, and an explicit -std= flag will be used to achieve it if necessary.

through the use of CMAKE_EXPORT_COMPILE_COMMANDS i can see the exact compiler options used to build runtime.cpp (the one with the errors)

mkdir build && cd build
cmake .. -DSD_VULKAN=ON
CMAKE_EXPORT_COMPILE_COMMANDS=1  cmake --build . --config Release
grep runtime.cpp compile_commands.json  | grep command

When i do this, i do not see -std=c++17 (or any other C++ version) being specified for this file. which is consistent with the hypothesis it is not being set because default is already c++20

/usr/lib64/ccache/c++ -DGGML_MAX_NAME=128 -DGGML_USE_CPU -DGGML_USE_VULKAN -DHAVE_INDEX_HTML -DSD_USE_WEBM -DSD_USE_WEBP -I/home/user/git/stable-diffusion.cpp/examples -I/home/user/git/stable-diffusion.cpp/examples/server/frontend/dist -I/home/user/git/stable-diffusion.cpp/. -I/home/user/git/stable-diffusion.cpp/src -I/home/user/git/stable-diffusion.cpp/include -I/home/user/git/stable-diffusion.cpp/thirdparty -I/home/user/git/stable-diffusion.cpp/ggml/src/../include -I/home/user/git/stable-diffusion.cpp/thirdparty/. -I/home/user/git/stable-diffusion.cpp/thirdparty/libwebp/src -I/home/user/git/stable-diffusion.cpp/thirdparty/libwebp -I/home/user/git/stable-diffusion.cpp/thirdparty/libwebm -O3 -DNDEBUG -o CMakeFiles/sd-server.dir/runtime.cpp.o -c /home/user/git/stable-diffusion.cpp/examples/server/runtime.cpp

My recommendation is that we ensure -std=c++17 to be set explicitly both to resolve this compiler issue, and also to ensure that people with newer compilers don't accidentally introduce new C++ features to the codebase that would break those with older toolchains.

i think we can accomplish that by doing something like:

set_target_properties(${TARGET} PROPERTIES C_STANDARD 11 C_STANDARD_REQUIRED ON CXX_STANDARD 17 CXX_STANDARD_REQUIRED ON)