Bugzilla – Bug 1217820
the existence of fmt-9 in factory breaks users of spdlog due to spdlog's ABI depending on fmt's ABI
Last modified: 2023-12-30 16:59:13 UTC
Right now spdlog-devel is broken on the ARM ports as it pulls in fmt 10 headers while the library itself exports fmt 9 types. (I do not have an arm machine and only noticed this because vscode fails to build) What's worse, spdlog exports fmt types as part of its ABI which in particular means that it breaks abi without soname bump whenever fmt breaks abi. This would be less of a problem if fmt-9 were simply dropped from the distro (due to broken deps triggering a rebuild), but as it still exists, every spdlog consumer must also be manually rebuilt.
FWIW riscv seems also broken (Don't know if it's temporary or not as building against :snapshot for riscv never actually worked)
Hi This is also broken in x86_64 with sway/hyprland and waybar not starting with the following error; ``` waybar: symbol lookup error: waybar: undefined symbol: _ZN6spdlog7details7log_msgC1ENS_10source_locEN3fmt2v917basic_string_viewIcEENS_5level10level_enumES6_ ``` I also don't see the patch mentioned in the changelog in the build, 2823.patch, there is no pull 2823, I'm assuming it's actually 2923, https://github.com/gabime/spdlog/pull/2923 Rolling back to the 1.12.0-3.1 build of libspdlog1_12 works.
There is no changelog entry because there is no source change in spdlog which broke this. The problem is that spdlog's soname does not incorporate fmt's, while its ABI changes based on the signatures of fmt types. This would not be a problem if there were only one fmt version in factory.
(In reply to Malcolm Lewis from comment #2) > Hi > This is also broken in x86_64 with sway/hyprland and waybar not starting > with the following error; > > ``` > waybar: symbol lookup error: waybar: undefined symbol: > _ZN6spdlog7details7log_msgC1ENS_10source_locEN3fmt2v917basic_string_viewIcEEN > S_5level10level_enumES6_ For this one I triggered rebuilds for everything potentially behind fmt10 (for snapshot 1205). The issue with waybar is/was: waybar linked libfmt.so.9 waybar also linked spdlog, which in turn linked libfmt.so.10 in fact, waybar thus resulted with two fmt versions in memory which clashed.
the problem is not two fmt versions clashing (different versions have symbols in different C++ namespaces). The problem is spdlog changing its set of exported symbols after rebuild.
Same for cryfs: > ben@skylab:~> /usr/bin/cryfs > /usr/bin/cryfs: symbol lookup error: /usr/bin/cryfs: undefined symbol: _ZN6spdlog7details7log_msgC1ENS_10source_locEN3fmt2v917basic_string_viewIcEENS_5level10level_enumES6_ > ben@skylab:~> rpm -q cryfs > cryfs-0.11.3-3.1.x86_64 > ben@skylab:~> ldd /usr/bin/cryfs | grep spd > libspdlog.so.1.12 => /lib64/libspdlog.so.1.12 (0x00007f368e4f2000) > ben@skylab:~> ldd /usr/bin/cryfs | grep fmt > libfmt.so.9 => /lib64/libfmt.so.9 (0x00007fb339b15000) > libfmt.so.10 => /lib64/libfmt.so.10 (0x00007fb338b2f000) > ben@skylab:~> rpm -q libfmt10 > libfmt10-10.1.1-1.1.x86_64 > ben@skylab:~> rpm -q libfmt9 > libfmt9-9.1.0-1.1.x86_64 > ben@skylab:~> rpm -q libspdlog1_12 > libspdlog1_12-1.12.0-3.2.x86_64
(In reply to Benjamin Greiner from comment #6) > Same for cryfs: cryfs had been triggered as well for snapshot 1205 (publishing should happen later this evening)
the LegacyX86 port is still broken
Seems like the package "bear" is broken on x86_64, the missing symbol's name is the same
(In reply to Laszlo from comment #9) > Seems like the package "bear" is broken on x86_64, the missing symbol's name > is the same Bear fails to build: https://build.opensuse.org/package/live_build_log/openSUSE:Factory/Bear/standard/x86_64
still to be reviewed: 1133041 State:new By:jengelh When:2023-12-14T09:48:49 Created by: jengelh submit: home:jengelh:branches:devel:libraries:c_c++/spdlog@3 -> devel:libraries:c_c++ Descr: - Add some symbol versions to ease rebuilds and transition on user systems when fmt changes [boo#1217820]
The glob you used in the linker script is wrong. `v10` has three characters as opposed to `v9`'s two therefore the mangled name changes. Also there are some exported symbols in `fmt::v10::detail` which aren't caught (they look like inline functions though — unsure what to do with them as the program may re-export them in that case)
created request id 1135772