Bug 1217820

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