Open tgs opened 2 years ago
Probably not a long-term solution either: libcppyy_backend.so
will merge with libCling.so
in the medium term (there is an on-going cleanup effort) and libCling.so
is provided as a wheel (since it takes quite some time to build on most systems).
What might work, is using gcc --print-file-name=libstdc++.so
and loading the result of that.
In my organization,
/lib64/libstdc++.so
is quite old. More recent compilers are available, in particular gcc 7.3. That's new enough to compile cppyy since it supports-std=c++1z
. This is set up so that any resulting object files, includinglibcppyy_backend.so
, have an RPATH pointing to the corresponding libstdc++ under /opt/.This can cause a problem with
_stdcpp_fix.py
if no other C++ code has been linked into the process yet -_stdcpp_fix
will link in/lib64/libstdc++.so
, which is actually too old to letlibcppyy_backend.so
work!This is not actually an issue in our full application, because we use several different C++ components loaded by various means, and a recent libstdc++ gets linked before
_stdcpp_fix
runs. So I am only having this problem when running unit tests of the cppyy-based component.I might suggest consulting the RPATH of
libcppyy_backend.so
when deciding which libstdc++ to load? I guess the whole algorithm is complicated and recursive but maybe the standard library is simple enough that consulting the first RPATH is enough?If that doesn't seem like a clean fix (or is not possible or something), then that's okay - I can live with setting LD_LIBRARY_PATH for the tests.