search

RenderKit / ospray

An Open, Scalable, Portable, Ray Tracing Based Rendering Engine for High-Fidelity Visualization
http://ospray.org
Apache License 2.0
997 stars 182 forks source link

ABI issue with std::string an prebuilt binaries #419

Closed paulmelis closed 4 years ago

paulmelis commented 4 years ago

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 aka ospray::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 aka ospray::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 in libstdc++, with std::__cxx11::string being the newer (and apparently default) one. Do the prebuilt binaries purposely use the older gcc4-compatible version?

johguenther commented 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.

paulmelis commented 4 years ago

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.