I'm developing two slightly different IOT projects, sharing a large part of the code base, and we are using GCC 6.3.0 due to compatibility requirements. To help in part of the code, I included the fmt library with the suggested CMake method:
include(FetchContent)
FetchContent_Declare(
fmt
GIT_REPOSITORY https://github.com/fmtlib/fmt
GIT_TAG 11.0.2)
FetchContent_MakeAvailable(fmt)
# later ...
target_link_libraries(<my helper library target> PRIVATE fmt)
However, compilation succeeds in one project, and fails in the other with
[8/17] Building CXX object _deps/fmt-build/CMakeFiles/fmt.dir/src/format.cc.o
FAILED: _deps/fmt-build/CMakeFiles/fmt.dir/src/format.cc.o
/opt/cross/bin/arm-linux-gnueabihf-g++ --sysroot=/opt/box-root-fs -I/opt/box-root-fs/usr/include -I/opt/box-root-fs/usr/local/include -I/home/abertulli/<project-source-root>/build/_deps/fmt-src/include -fdiagnostics-color=always -pthread -g -MD -MT _deps/fmt-build/CMakeFiles/fmt.dir/src/format.cc.o -MF _deps/fmt-build/CMakeFiles/fmt.dir/src/format.cc.o.d -o _deps/fmt-build/CMakeFiles/fmt.dir/src/format.cc.o -c /home/abertulli/<project-source-root>/build/_deps/fmt-src/src/format.cc
In file included from /home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/format.h:41:0,
from /home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/format-inl.h:27,
from /home/abertulli/<project-source-root>/build/_deps/fmt-src/src/format.cc:8:
/home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/base.h: In instantiation of ‘void fmt::v11::detail::check_format_string(S) [with Args = {unsigned int&}; S = fmt::v11::formatter<fmt::v11::detail::bigint>::format(const fmt::v11::detail::bigint&, fmt::v11::format_context&) const::<lambda()>::FMT_COMPILE_STRING; typename std::enable_if<std::is_base_of<fmt::v11::detail::compile_string, S>::value, int>::type <anonymous> = 0]’:
/home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/base.h:2887:41: required from ‘fmt::v11::basic_format_string<Char, Args>::basic_format_string(const S&) [with S = fmt::v11::formatter<fmt::v11::detail::bigint>::format(const fmt::v11::detail::bigint&, fmt::v11::format_context&) const::<lambda()>::FMT_COMPILE_STRING; typename std::enable_if<(std::is_convertible<const S&, fmt::v11::basic_string_view<Char> >::value || (std::is_base_of<fmt::v11::detail::compile_string, S>::value && std::is_constructible<fmt::v11::basic_string_view<Char>, const S&>::value)), int>::type <anonymous> = 0; Char = char; Args = {unsigned int&}]’
/home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/format-inl.h:1391:60: required from here
/home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/base.h:2792:56: in constexpr expansion of ‘fmt::v11::detail::parse_format_string<true, char, fmt::v11::detail::format_string_checker<char, unsigned int> >(s, fmt::v11::detail::format_string_checker<char, unsigned int>(s))’
/home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/base.h:2613:44: in constexpr expansion of ‘fmt::v11::detail::parse_replacement_field<char, fmt::v11::detail::format_string_checker<char, unsigned int>&>((p + 4294967295u), end, ((fmt::v11::detail::format_string_checker<char, unsigned int>&)handler))’
/home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/base.h:2591:13: in constexpr expansion of ‘(& handler)->fmt::v11::detail::format_string_checker<Char, Args>::on_format_specs<char, {unsigned int}>(adapter.fmt::v11::detail::parse_replacement_field(const Char*, const Char*, Handler&&) [with Char = char; Handler = fmt::v11::detail::format_string_checker<char, unsigned int>&]::id_adapter::arg_id, (begin + 1u), end)’
/home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/base.h:2763:51: in constexpr expansion of ‘((fmt::v11::detail::format_string_checker<char, unsigned int>*)this)->fmt::v11::detail::format_string_checker<char, unsigned int>::parse_funcs_[id](((fmt::v11::detail::format_string_checker<char, unsigned int>*)this)->fmt::v11::detail::format_string_checker<char, unsigned int>::context_)’
/home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/base.h:2677:55: in constexpr expansion of ‘fmt::v11::formatter<unsigned int, char, void>().fmt::v11::formatter<unsigned int, char, void>::<anonymous>.fmt::v11::detail::native_formatter<T, Char, TYPE>::parse<fmt::v11::detail::compile_parse_context<char> >(ctx)’
/home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/base.h:2829:34: in constexpr expansion of ‘fmt::v11::detail::parse_format_specs<char>((& ctx)->fmt::v11::detail::compile_parse_context<char>::<anonymous>.fmt::v11::basic_format_parse_context<Char>::begin<char>(), (& ctx)->fmt::v11::detail::compile_parse_context<char>::<anonymous>.fmt::v11::basic_format_parse_context<Char>::end<char>(), ((fmt::v11::detail::native_formatter<unsigned int, char, (fmt::v11::detail::type)2>*)this)->fmt::v11::detail::native_formatter<unsigned int, char, (fmt::v11::detail::type)2>::specs_, (& ctx)->fmt::v11::detail::compile_parse_context<char>::<anonymous>, (fmt::v11::detail::type)2)’
/home/abertulli/<project-source-root>/build/_deps/fmt-src/include/fmt/base.h:2792:77: internal compiler error: in cxx_eval_bit_field_ref, at cp/constexpr.c:2360
FMT_CONSTEXPR bool error = (parse_format_string<true>(s, checker(s)), true);
^
The two CMakeLists.txt files are identical when including fmt, they only slightly change when using it (like, using two versions of target_link_libraries), but it compiles just fine if I do a native build (that uses GCC 11.4), and from the error message it doesn't seem related to my source file that uses it (which in any case it's identical). I get that ICE are basically bugs that shouldn't be there, since they show up when compiling valid code, but I'm puzzled by why it shows up in one case but not the other. I'm sorry I can't provide a full MWE without breaking my NDA (and the compiler, since it's not in the repo anymore, was compiled from scratch adapting this (blessed!) guide
The short answer here is "yes".
Since an ICE is just a bug in the compiler, it can happen for pretty much any reason. Since GCC was a pretty mature product even in that ancient version 6, most of its remaining ICE's happened in corner cases, typically including multiple factors so that the ICE didn't show up in GCC's extensive test suite.
"Difference in included headers" just means that the compiler compiled different code. Obviously the compiler input matters a lot to determine whether an ICE happens.