Linking error with GCC-compiled fmt and Clang-compiled folly, only on Fedora rawhide ppc64le

[michel-slm]

Fedora 36 upgraded GCC to version 12: https://fedoraproject.org/wiki/Changes/GNUToolchainF36

It also switched ppc64le from the numerically problematic IBM extended long double to
IEEE 754 quad long double: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NPKWMTSJ2A2ABNJJEH6WTZIAEFTX6CQY/#FDILCGZPOMB7VVJQQBCJO5GVBIEOWHHA - which could be relevant, as the error is in some floating point code.

Because of some regressions I am switching Fedora's folly package to use clang instead of GCC; on x86_64, i686, and aarch64 it builds fine (chasing some test failures esp on non-x86_64), but on ppc64le it fails:

Fedora 36
https://koji.fedoraproject.org/koji/taskinfo?taskID=83649017

Rawhide (F37)
https://kojipkgs.fedoraproject.org//work/tasks/1021/83611021/build.log

[ 35%] Linking CXX executable logging_example
cd /builddir/build/BUILD/folly-2022.02.28.00/redhat-linux-build/folly/logging/example && /usr/bin/cmake -E cmake_link_script CMakeFiles/logging_example.dir/link.txt --verbose=1
/usr/bin/clang++ -O2 -flto -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS --config /usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong   -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now   -flto -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/folly-2022.02.28.00/.package_note-folly-2022.02.28.00-2.fc37.ppc64le.ld -rdynamic CMakeFiles/logging_example.dir/main.cpp.o -o logging_example  -Wl,-rpath,/builddir/build/BUILD/folly-2022.02.28.00/redhat-linux-build/folly/logging/example:/builddir/build/BUILD/folly-2022.02.28.00/redhat-linux-build liblogging_example_lib.so ../../../libfolly.so.2022.02.28.00 /usr/lib64/libfmt.so.8.1.1 -Wl,--as-needed -lboost_context -lboost_filesystem -lboost_program_options -lboost_regex -lboost_system -lboost_thread -pthread -lboost_chrono -lboost_date_time -lboost_atomic -ldouble-conversion /usr/lib64/libgflags.so.2.2.2 -lglog -levent -lz -lssl -lcrypto -lbz2 -llz4 -lzstd -lsnappy -ldwarf -Wl,-Bstatic -liberty -Wl,-Bdynamic -laio -luring -lsodium -ldl -lunwind -latomic 
/usr/bin/ld: ../../../libfolly.so.2022.02.28.00: undefined reference to `int fmt::v8::detail::format_float<__float128>(__float128, int, fmt::v8::detail::float_specs, fmt::v8::detail::buffer<char>&)'
/usr/bin/ld: ../../../libfolly.so.2022.02.28.00: undefined reference to `int fmt::v8::detail::snprintf_float<__float128>(__float128, int, fmt::v8::detail::float_specs, fmt::v8::detail::buffer<char>&)'
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

Not sure what could be causing this, any pointers to narrowing this down would be highly appreciated.

[michel-slm]

tracking on the Fedora side in https://bugzilla.redhat.com/show_bug.cgi?id=2061022

[vitaut]

{fmt} is being switched to the internal floating-point formatter and quad precision (binary128) support is WIP. Note that it only affects the development version (master), not released {fmt} versions. Released versions support standard floating-point types: float, double and long double.

[sharkcz]

__float128 is an (new) internal representation of long double, it should be transparent for regular C/C++ code ... I wonder if it could be wrong C++ code where the instantiation of the template happens in a different translation unit than the caller is.

[vitaut]

My guess is that the library and the code that uses it are compiled with incompatible options. In general mixing clang and gcc is discouraged because they are not fully ABI compatible. One potential workaround is to add instantiations for __float128 in

fmt/src/format.cc

Lines 103 to 111 in b6f4cea

	template FMT_API int detail::snprintf_float(double, int, detail::float_specs,
	detail::buffer<char>&);
	template FMT_API int detail::snprintf_float(long double, int,
	detail::float_specs,
	detail::buffer<char>&);
	template FMT_API int detail::format_float(double, int, detail::float_specs,
	detail::buffer<char>&);
	template FMT_API int detail::format_float(long double, int, detail::float_specs,
	detail::buffer<char>&);

[sharkcz]

I agree the mixing of gcc and clang objects could be problematic, I will try to get feedback on this issue from our toolchain too.

[michel-slm]

yeah, sadly we're forced to do this at the moment. Those instantiations would need to be added to Fedora's fmt I guess?

[vitaut]

Those instantiations would need to be added to Fedora's fmt I guess?

Yes.

[dfaggioli]

Hello, just FYI, we're seeing the same problem on openSUSE Tumbleweed (also on GCC 12).

In fact, when building QEMU for ppc64le, the configure script fails with this error:

[  111s] Has header "rbd/librbd.h" : YES 
[  111s] Library rbd found: YES
[  111s] 
[  111s] ../meson.build:880:6: ERROR: Problem encountered: librbd >= 1.12.0 required

But the problem is not really the library version. Rather, the checker script is trying to build a simple program, and the same errors reported in the description of this issue are encountered. See some more details here: https://bugzilla.opensuse.org/show_bug.cgi?id=1135030#c12

In our case, however, I don't think there is any gcc and clang mismatch. Or, at least, I'm building QEMU with GCC and, AFAIK, the ceph maintainers are doing the same. Some build logs should be available at these pages:

• https://build.opensuse.org/package/show/Virtualization/qemu (click on the red 'failed' link, next to ppc64, below "openSUSE_Tumbleweed" [1])
• https://build.opensuse.org/package/show/filesystems:ceph/ceph (although, the ppc64le build is disabled, so logs are not available, mm...)

[1] This should be the URLs, but the content changes, as new builds are attempted, so I preferred to give instructions on how to reach it as well:

• https://build.opensuse.org/package/live_build_log/Virtualization/qemu/openSUSE_Tumbleweed/ppc64le
• https://build.opensuse.org/build/Virtualization/openSUSE_Tumbleweed/ppc64le/qemu/_log

[dfaggioli]

• https://build.opensuse.org/package/show/Virtualization/qemu (click on the red 'failed' link, next to ppc64, below "openSUSE_Tumbleweed" [1])
• https://build.opensuse.org/package/show/filesystems:ceph/ceph (although, the ppc64le build is disabled, so logs are not available, mm...)

Ok, I branched the package, and enabled ppc64le builds in my home project. Here it should be possible to see build logs:

• https://build.opensuse.org/package/show/home:dfaggioli:experimental:ceph/ceph
• https://build.opensuse.org/package/live_build_log/home:dfaggioli:experimental:ceph/ceph/openSUSE_Tumbleweed_PowerPC/ppc64le
• https://build.opensuse.org/build/home:dfaggioli:experimental:ceph/openSUSE_Tumbleweed_PowerPC/ppc64le/ceph/_log

[vitaut]

Is the log link correct? I'm seeing a different error

[10964s] /home/abuild/rpmbuild/BUILD/ceph-16.2.7-654-gd5a90ff46f0/build/boost/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of '255' from 'int' to 'char' [-Wnarrowing]
[10964s]    83 |     public detail::integer_traits_base<char, CHAR_MIN, CHAR_MAX>
[10964s]       |                                                                ^

in https://build.opensuse.org/public/build/home:dfaggioli:experimental:ceph/openSUSE_Tumbleweed_PowerPC/ppc64le/ceph/_log.

[vitaut]

format_float and snprintf_float have been moved to fmt/format.h to support non-standard floating point formats such as __float128 and compile-time FP formatting. This should resolve the current issue as well.