I'm in process of upgrading from 2020.1 to 2021.4.2. Forget having to reimplement custom layers -- this has pretty much become a norm for the SDK. But now we seem to run into C++ ABI problems, which has never been a problem before.
We build our library, dependent on OpenVino with libstd++11/CXX11 ABI. That was compatible with all the prior version.
However, linking against libgraph, and attempting to run, our library fails to load with
/src/.build.linux/package/./lib/libvinonodes.so: undefined symbol: _ZNK6ngraph4Node8evaluateERKSt6vectorISt10shared_ptrINS_7runtime10HostTensorEESaIS5_EES9_RKSt3mapINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES2_INS_7VariantEESt4lessISG_ESaISt4pairIKSG_SI_EEE
The symbol seems to exist in the library, but with a legacy C++ ABI:
insectoidsombrero@dde4fb5b07ab:/src/.build.linux$ readelf -Ws libngraph.so | grep _ZNK6ngraph4Node8evaluateERKSt6vectorISt10shared_ptrINS_7runtime10HostTensor
482: 000000000015ec90 54 FUNC GLOBAL DEFAULT 11 _ZNK6ngraph4Node8evaluateERKSt6vectorISt10shared_ptrINS_7runtime10HostTensorEESaIS5_EES9_RKSt3mapISsS2_INS_7VariantEESt4lessISsESaISt4pairIKSsSC_EEE
4075: 000000000015ec60 46 FUNC GLOBAL DEFAULT 11 _ZNK6ngraph4Node8evaluateERKSt6vectorISt10shared_ptrINS_7runtime10HostTensorEESaIS5_EES9_
So, what now? Do have to build OpenVino from source, rather than using Intel distribution? If so, are there steps documenting how the Intel distribution is created?
Also, why has this always worked? We've been using Intel Distribution of OpenVino since the very beginning; and used the C++11 ABI this entire time; why do you think this only became a problem now?
And it does look to be a recent regression. I've removed the dependency on ngraph, and ran into a problem with libinference_engine, which was successfully used with 2020.2:
symbol lookup error: /src/.build.linux/package/./lib/PipelineNodes/libvinonodes.so: undefined symbol: _ZN15InferenceEngine4CoreC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
Comparing the old and new libraries:
$:/src/.build.linux$ readelf -Ws ~/.conan/data/openvino/2020.2.117.75+1a81692b/ci/master/package/4db1be536558d833e52e862fd84d64d75c2b3656/lib/libinference_engine.so | grep _ZN15InferenceEngine4CoreC1ER
844: 00000000000a7d70 641 FUNC GLOBAL DEFAULT 11 _ZN15InferenceEngine4CoreC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
$:/src/.build.linux$ readelf -Ws ~/.conan/data/openvino/2021.4.752.78+afa68f48/ci/branch_feat_2021R4.2/package/4db1be536558d833e52e862fd84d64d75c2b3656/lib/libinference_engine.so | grep _ZN15InferenceEngine4CoreC1ER
1788: 000000000010cd50 891 FUNC GLOBAL DEFAULT 11 _ZN15InferenceEngine4CoreC1ERKSs
Thanks for reaching out to us.
Looking at the Release Notes of Intel® Distribution of OpenVINO™ Toolkit 2020, the supported and validated Operating System are Ubuntu 18.04 (Bionic Beaver) and Ubuntu 16.04 (Xenial Xerus).
While for Intel® Distribution of OpenVINO™ Toolkit 2021, the supported and validated Operating System are Ubuntu 18.04 (Bionic Beaver) and Ubuntu 20.04 (Focal Fossa).
We understand your frustration, and we’ve reached out to our Engineering team for updates on this issue.
Please expect a delay due to the holiday season, and thank you for your patience.
According to Dual ABI (gnu.org), your C+11 ABI library is generated using older GCC version but you are migrating to our latest OpenVINO™ version. We would recommend you rebuild your library as mentioned in the document in Troubleshooting section.
"If you get linker errors about undefined references to symbols that involve types in the std::__cxx11 namespace or the tag [abi:cxx11] then it probably indicates that you are trying to link together object files that were compiled with different values for the _GLIBCXX_USE_CXX11_ABI macro. This commonly happens when linking to a third-party library that was compiled with an older version of GCC. If the third-party library cannot be rebuilt with the new ABI then you will need to recompile your code with the old ABI."
I'm well aware of this. In fact, I may have pointed it out in my original post.
Unfortunately, our library is using C++11 ABI. As do its dependencies other than OpenVino. As do its consumers. And as, in fact, did OpenVino shipped by Intel prior to v2020.3, and as still does every other flavor of OpenVino binary shipped today (including those shipped by Intel for Bionic/Focal).
So yes, the value of _GLIBCXX_USE_CXX11_ABI does need to change -- however, it needs to change for the build of Xenial OpenVino binaries, and not elsewhere. It's a clear regression, and it needs to be fixed.
Hope that helps.
We really appreciate your support in using OpenVINO™ since the very beginning of its releases.
OpenVINO™ has undergo various improvements to cater with new dependencies requirements so that we are able to offer up-to-date feature capabilities.
As per our Release Notes, our latest version (2021.4.2) is validated with GCC 7.5 (Ubuntu 18) and GCC 9.3 (Ubuntu 20) and other than these versions, they are incompatible with our latest release as confirmed by our engineering team. This is why we had proposed the workaround on potentially rebuilding your C++11 (GCC 4.x) library as in our initial reply.
We understood your requirement to continue use C++11 AB library due to their respective dependencies and with that, I will assist you to initiate this as feature request to our development team to potentially assess this requirement.
I shall keep you posted on any updates once available.
Thank you for your patience and continuous support of OpenVINO™ Toolkit.
As it was written - since 2021.x for Ubuntu 16.x version OpenVINO is not provided as a prebuilt package, while you still can compile OpenVINO from sources.
So, the question is - what binaries do you use on your system? I suppose those are binaries for CentOS which are compiled with gcc 4.x and so they have names like:
InferenceEngine::Core::Core(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
While the proper names for gcc 5 and higher MUST be with __cxx11 tag like:
InferenceEngine::Core::Core(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
1. Migrate to newer OS like Ubuntu 18.x
2. Recompile OpenVINO from scratch on your system using https://github.com/openvinotoolkit/openvino/wiki/BuildingForLinux
I get the choices currently available -- and yes, we opted to running on 18.04 only for now. That being said, I'm struggling to find a rationale for regressing to an older C++ ABI, compared to v2020.2 and prior. What requirement drove that change? "Lets go back to the world that was 20 years ago" is not something that is very common when it comes to software
Again - we don't have any regression. The only change - Ubuntu 16.x is excluded from officially supported OSes (but you still compile for this OS from sources).
The supported ones for 2021.4.x: CentOS with gcc 4.x, Ubuntu 18 / RHEL with gcc7 and Ubuntu 20 with gcc9.
So, you tried to use CentOS compiled binaries, but for sure they are not compatible with U16 ones because of gcc abi tag.
OpenVINO is just compiled with default compiler of the system and provided to the users as is. What is your suggestion to improve the situation?
Thank you for your question. If you need any additional information from Intel, please submit a new question as this thread is no longer being monitored.