Closed paulmelis closed 4 years ago
For the OSPRay core library we chose to have a C99 API to avoid such ABI problems (for example when interfacing with Python). For ospray-testing
(which is not really meant to be used by applications), having an (undocumented and potentially unstable) C++ API, we cannot make such guaranties.
We like the binary packages to run on CentOs 7 as lowest common denominator, which is why we use a rather old gcc / stdlibs.
No need to reopen the issue, but just a remark:
For ospray-testing (which is not really meant to be used by applications), having an (undocumented and potentially unstable) C++ API, we cannot make such guaranties.
Actually, ospray-testing is quite useful during development with ospray as it provides a variety of known-good scenes. I actually got the impression from @jeffamstutz that making ospray-testing available wasn't much of a problem. I guess it's the current C++-only API that is causing this issue.
I was updating ospray-python to the 2.1 API and was inadvertently compiling against my local superbuild while the runtime environment pointed to the prebuilt 2.1.1 binaries. I am calling some routines from ospray_testing, most notably
newBuilder(const std::string &type)
.The dynamic linker reported a missing symbol:
_ZN6ospray7testing10newBuilderERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
akaospray::testing::newBuilder(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
.Indeed,
libospray_testing.so
in the binaries only has_ZN6ospray7testing10newBuilderERKSs
akaospray::testing::newBuilder(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
.Reading https://stackoverflow.com/a/49119902 it seems there's two
std::string
implementations inlibstdc++
, withstd::__cxx11::string
being the newer (and apparently default) one. Do the prebuilt binaries purposely use the older gcc4-compatible version?