openal-soft icon indicating copy to clipboard operation
openal-soft copied to clipboard

C++ diamond dependency on `fmt`

Open anonymouspc opened this issue 6 months ago • 1 comments

Hello. My project both depends on OpenAL and fmtlib via C++20 modules. And, as you see, OpenAL has an internal fmt-11.2.0.

This causes disaster when linking them together, especially when almost all code in fmt is template (that is, inlined, and should obey the ODR rule). Linkers complains about symbols are duplicated.

Could we use a cmake find_package()/FetchContent_Declare() instead? We can then build the openal itself, or provide a specific -DCMAKE_PREFIX_PATH=<custom_fmt_install_path> when needed. Because fmt is modulized, we can even import fmt!

Thank you! This is an amazing library and I will star it :)

anonymouspc avatar Sep 11 '25 15:09 anonymouspc

Hello. My project both depends on OpenAL and fmtlib via C++20 modules. And, as you see, OpenAL has an internal fmt-11.2.0.

This causes disaster when linking them together, especially when almost all code in fmt is template (that is, inlined, and should obey the ODR rule). Symbols are duplicated.

Hi. This shouldn't actually be a problem, since the fmtlib version OpenAL Soft uses is modified slightly to use a different inline namespace, which causes the symbols to be given different names and not violate the ODR rule. The default fmtlib uses a v11 inline namespace, so the symbol names are all fmt::v11::..., while OpenAL Soft's internal copy uses alsoft_v11, so those symbol names are all fmt::alsoft_v11::..., keeping them distinct even when linked into the same binary.

kcat avatar Sep 11 '25 16:09 kcat