Thanks for your reply. It inspired me to do some further research. The
response by Jonathan Wakely to this StackOverflow question:
https://stackoverflow.com/questions/46746878/is-it-safe-to-link-c17-c14-a...
indicates that, as a *GCC-specific* guarantee, C++ code is
ABI-compatible across language standards. (There is more nuance when
mixing GCC versions, which doesn’t apply here.)
So I think that you are right, at least as the situation applies to
Fedora, and I retract my claims. The situation I referenced in grpc is
(while real) not an *ABI* incompatibility, and building with upstream’s
default C++ standard version should generally be the right thing to do.
On 8/23/21 11:35 AM, Ian McInerney via devel wrote:
> On Mon, Aug 23, 2021 at 4:13 PM Ben Beasley <code(a)musicinmybrain.net
> <mailto:code@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_002...
>
<
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#C_002...>),
> 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(a)lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> > To unsubscribe send an email to
> devel-leave(a)lists.fedoraproject.org
> <mailto:devel-leave@lists.fedoraproject.org>
> > Fedora Code of Conduct:
>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <
https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> > List Guidelines:
>
https://fedoraproject.org/wiki/Mailing_list_guidelines
> <
https://fedoraproject.org/wiki/Mailing_list_guidelines>
> > List Archives:
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
<
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
> > Do not reply to spam on the list, report it:
>
https://pagure.io/fedora-infrastructure
> <
https://pagure.io/fedora-infrastructure>
> >
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> <mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> <mailto:devel-leave@lists.fedoraproject.org>
> Fedora Code of Conduct:
>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <
https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> List Guidelines:
>
https://fedoraproject.org/wiki/Mailing_list_guidelines
> <
https://fedoraproject.org/wiki/Mailing_list_guidelines>
> List Archives:
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
<
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
> Do not reply to spam on the list, report it:
>
https://pagure.io/fedora-infrastructure
> <
https://pagure.io/fedora-infrastructure>
>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
>