On Mon, Aug 23, 2021 at 4:13 PM Ben Beasley <c...@musicinmybrain.net> wrote:
> 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. > No, I don't think that this is a safe thing to do on a distribution level - overriding the chosen C++ standard of a project is not respecting upstream's decision, and could cause problems. For example, if upstream wants C++11 and uses std::auto_ptr, compiling with C++17 or C++20 would then break compilation because it was removed in those standard versions. > > 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. > > Do you have a reference for that? I thought the C++ ABI we are talking about here is compiler-dependent and not standard-depdenent (e.g. https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#C_002b_002b-Dialect-Options), so there is the possibility of having problems if we build half the distro with one GCC version and the other half with a different one (hence why we generally do a mass rebuild after the GCC toolchain is updated to its new stable ABI). While there has been one very large change to my knowledge (e.g. std::string in C++11), the C++ standard seems to have tried very hard (to the point of rejecting changes that would violate it) to allow the ABI to be forward compatible between standard versions > 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-le...@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 > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
