Installed RPATHs for non-cmake binaries can point to the wrong directory

[jabraham17]

When non-cmake related binaries are built, they use the RPATHs from the chpl compiler in the source tree. If the RPATHs are embedded in the binary, then if those binaries are installed they will have the wrong paths.

For binaries like chpl and libFrontendShared, cmake handles the fixups needed for the RPATHs. However, something like chapel-py does not use cmake, and so will have the wrong RPATH.

Steps to replicate

cd chapel-src

./configure --prefix=/usr
make all # build chpl compiler
make chplcheck chpl-language-server # builds chapel-py
make install # install to /usr
cd ..
# I built Chapel and installed it, I can delete the source tree
rm -rf chapel-src

/usr/bin/chplcheck # error, can't find libFrontendShared

This problem exists for something like the linux packages, but is worked around by running util/packaging/common/fixpaths.py as a post-processing step.

However, this problem exists for users who may wish to run make install themselves. To fix this, I think we can just move the fixpaths script out of the packaging builds and into util/buildRelease/install.sh

Related issue: https://github.com/chapel-lang/chapel/issues/25356

[mppf]

Maybe a dumb question, but can we have chapel-py use cmake?

[jabraham17]

Not a dumb question, I think chapel-py using cmake is a possibility. We use setuptools because that is simplest and requires the least extra dependencies. Based on https://packaging.python.org/en/latest/guides/tool-recommendations/#build-backends, [scikit-build-core](https://packaging.python.org/en/latest/key_projects/#scikit-build-core) may be a good alternative that allows us to use CMake.

However, I am not sure just switching to CMake solves the problem automatically. We would still need to handle the different install scenarios and integrate with our existing chpl-venv stuff. But I would also like to see us improve the build system for chapel-py so this may be a good opportunity.

[mppf]

However, I am not sure just switching to CMake solves the problem automatically.

We still need to pay attention to it and plan for it in the cmake sources. But the fact that CMake has builtin support for doing rpath adjustments when installing means we can get that as well without having to get too fancy with scripts etc.