problem with too-long python shebangs
I am encountering a paraview superbuild issue when building catalyst on cee and on tlcc2 for use with the Sierra simulation engines. I have a workaround, but it’s a bad idea to do permanently.
The mesa third party library (OSMesa for catalyst) now exclusively uses a thing called “meson” to build, which in turn exclusively uses ninja (no cmake). During the configuration process in preparation for the mesa build meson or ninja creates various shell scripts which are to be executed during the build. The python that is loaded with the sierra-devel module (on cee and tlcc2 both, and cts1 as well) was created using spack. The path to the python executable looks like:
/snip/spack/linux-rhel7-x86_64/gcc-10.3.0/anaconda3-2021.05-hzr5w5v54sh3moi43gtl2fzdffebm2tf/bin/python
Which is 130 characters long. Due to some strange OS limits (lots of googling and reading here), if you try to put that path into a shell script as your interpreter (i.e. you do the !#(path to this python), which I believe is called a ‘shebang’), but that path exceeds 128 characters, it is then truncated to 80 characters (“/snip/spack/opt/spack/linux-rhel7-x86_64/gcc-10.3.0/anaconda3-2”). During the mesa build I am then informed that there is no such executable to use as the interpreter.
I don’t currently have this problem building catalyst for SPARC because they have their own python build with a much shorter path. It also use to be when you loaded an anaconda module on tlcc2 or cee you got much shorter paths to the python executable.
The workaround I am using is that I create an alias “/snip/sr1py” or the like and link it to the long-name directory above “/bin/python”, and then change all the environment variables (at least 5 or 6) which have the long name to use the short link name. This workaround works perfectly, but it is really bogus. This needs to be fixed, possibly in multiple ways:
I think (but am not sure) that the 128 character limit is an OS kernel setting. This should almost certainly be changed to 256 or some such, if possible. I doubt we can get SNL to rebuild and reinstall all the kernels, but maybe at least in upcoming rhel releases we could have it changed. Maybe.
snip
Paraview superbuild should not fail just because the full path to the python executable is more than 128 characters. The osmesa build should work even if the path to python is greater than 128 characters. The osmesa org should fix this and ideally we should have a patch of our own if necessary.
So: Alan, could you create a ParaView issue for this (tagged with superbuild)? Chris, can you look into getting us a shorter python path and/or getting the kernel limit number changed? Corey/Ben can you look at how superbuild could be fixed and/or how the mesa build could be fixed (and does a newer mesa not have this problem)?
My gut is that this is not a showstopper for 5.11.1 because I have a good workaround, but it definitely seems like something that needs fixing.
@ben.boeckel I couldn't find superbuild bug list. Thus, putting this here.