Description of problem: The binaries of applications installed with SCL do not set their RPATH to point to their libraries. I understand that there are good reasons in general to avoid using RPATH when building distribution packages but I feel that software collections are a special case of packaging. It is usual in Python development to create a virtualenv which creates an isolated environment which runs everything against a specific version of Python. It does this by making a copy of the appropriate Python executable into the virtualenv directory. Ordinarily this is fine since it is copying a system python binary which is linking against system python libraries. However, when using SCLs the python libraries aren't available in the system library search path. To make it work, as a user you have to enable both the SCL *and* the virtualenv before you can run python. Instead, if /opt/rh/python33/root/usr/bin/python3 sorted an RPATH of '$ORIGIN/../lib64' then the standard Python workflow would work. How reproducible: Always Steps to Reproduce: $ scl enable python33 -- virtualenv ~/scl_test $ ~/scl_test/bin/pip list Actual results: ~/scl_test/bin/pip: error while loading shared libraries: libpython3.3m.so.1.0: cannot open shared object file: No such file or directory Expected results: It should run the tool `pip` using the correct SCL version of Python.
Tomas, with https://bugzilla.redhat.com/show_bug.cgi?id=1479406 implemented for the Python collections in RHSCLs 3.0, can this be closed now?
Indeed I tested that the abovementioned RFE fixes this issue as well, though it's only fixed in rh-python36 (and any later versions), as python33 collection is EOL now.