Problem when recent libstdc++ is located by RPATH

[tgs]

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, including libcppyy_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 let libcppyy_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.

[wlav]

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.