I don’t have a clear explanation for why the outcome is arch-specific. I
do know that this has also been the case for some others who have
encountered similar problems in the past. (Some of the following bugs
were fixed, and some were not.)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608
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 a
On Mon, Aug 23, 2021 at 10:13 AM Ben Beasley
wrote:
> The same specialization of ProcessorCache:
>
>template class ProcessorCache;
>
> is explicitly instantiated in two different translation units:
>
> src/OpenColorIO/Processor.cpp
> src/OpenColorIO/Config.cpp
>
> which violates the C
On Mon, Aug 23, 2021 at 4:13 PM Ben Beasley wrote:
> The same specialization of ProcessorCache:
>
>template class ProcessorCache;
>
> is explicitly instantiated in two different translation units:
>
> src/OpenColorIO/Processor.cpp
> src/OpenColorIO/Config.cpp
>
> which violates the C+
The same specialization of ProcessorCache:
template class ProcessorCache;
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
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_tes
