The same specialization of ProcessorCache:
template class ProcessorCache<std::size_t, ProcessorRcPtr>;
is explicitly instantiated in two different translation units:
src/OpenColorIO/Processor.cpp src/OpenColorIO/Config.cpp
which violates the C++ standard (an explicit instantiation definition shall appear at most once in a program).
Since you are compiling with C++11 (vs. C++98), you can change the line in Config.cpp to
extern template class ProcessorCache<std::size_t, ProcessorRcPtr>;
and it should be fine (in theory, I haven’t run a scratch build).
-----
Side note: while CMake build systems tend to hard-code a C++ standard version, it’s better in my opinion if we can override it to match the default in GCC, currently C++17, since C++ code compiled with different standard versions is not ABI-compatible. For CMake, this often looks like -DCMAKE_CXX_STANDARD=17. (I don’t know a good way to obtain this value automatically.) To me, this is in the spirit of respecting the distribution’s build flags.
When each C++ library is compiled with its own upstream-preferred C standard version, it’s perfectly possible that an application might have dependencies using mutually exclusive C++ ABIs, in which case it would be impossible to package without bundled dependencies in Fedora. Or, things might appear to work but there could be problems at runtime or confusing linker errors down the road.
It’s not a theoretical problem: grpc builds as C++17, and links against abseil-cpp which builds as C++17, but runs its unit tests using gtest which is built in Fedora as C++11. This means grpc has to bundle its own copy of gtest and build it as C++17. In this case, gtest is not exactly a bundled library in the usual sense, since it can be proven that nothing from gtest is linked into the installed libraries or executables.
Of course, in some cases there are ecosystems of packages in Fedora that are all currently hard-coding C++11, which happens to work well for now—and adjusting one would mean adjusting them all. So the issue of C++ ABI version is a potentially ugly one either way.
On 8/23/21 10:19 AM, Richard Shaw wrote:
I'm working on updating OpenColorIO to 2.0.1 and building in a side tag, however, the build failed but only on armv7hf with:
usr/lib/libpystring.so /usr/lib/libyaml-cpp.so.0.6.3 ../testutils/libtestutils.a -lm ../../src/apputils/libapputils.a /usr/bin/ld: CMakeFiles/test_cpu_exec.dir/Processor_tests.cpp.o (symbol from plugin): in function `OpenColorIO_v2_0::ProcessorMetadata::ProcessorMetadata()': (.text+0x0): multiple definition of `typeinfo name for OpenColorIO_v2_0::ProcessorCache<unsigned int, std::shared_ptr<OpenColorIO_v2_0::Processor> >'; CMakeFiles/test_cpu_exec.dir/Config_tests.cpp.o (symbol from plugin):(.text+0x0): first defined here /usr/bin/ld: CMakeFiles/test_cpu_exec.dir/Processor_tests.cpp.o (symbol from plugin): in function `OpenColorIO_v2_0::ProcessorMetadata::ProcessorMetadata()': (.text+0x0): multiple definition of `typeinfo for OpenColorIO_v2_0::ProcessorCache<unsigned int, std::shared_ptr<OpenColorIO_v2_0::Processor> >'; CMakeFiles/test_cpu_exec.dir/Config_tests.cpp.o (symbol from plugin):(.text+0x0): first defined here collect2: error: ld returned 1 exit status
Ideas?
Thanks, Richard
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure