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-and-c11-objects
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@xxxxxxxxxxxxxxxxxx
<mailto:code@xxxxxxxxxxxxxxxxxx>> 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
<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@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:devel@xxxxxxxxxxxxxxxxxxxxxxx>
> To unsubscribe send an email to
devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:devel-leave@xxxxxxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxxxxxx
<https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
<https://pagure.io/fedora-infrastructure>
>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:devel@xxxxxxxxxxxxxxxxxxxxxxx>
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:devel-leave@xxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxxxx
<https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx>
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
<https://pagure.io/fedora-infrastructure>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
