I have two almost identical systems. I install software in system1 (a remote testing environment) in /export/apps/ and then rsync the files to system2 in its /export/apps. For file system reasons, /export/ is really a symlink on each system. This usually works b/c for most many programs, any hard-baked paths contain the symlink and the file structure under the symlink is identical. So
system1 : /export/ -> /gpfs0/remote-test/export
system2 : /export/ -> /gpfs0/export
However, when I set .libPaths in R, R 'helpfully' resolves the symlinks. I have a strong suspicion that when I rsync this to system2, those resolved symlinks are going to break the installed software. E.g. (in R/4.0.0)
> .libPaths = .libPaths("/export/apps/opt/monocle3/1.0.0/")
> .libPaths()
[1] "/gpfs0/remote-test/export/apps/opt/monocle3/1.0.0"
[2] "/gpfs0/export/apps/easybuild/software/R/4.0.0-foss-2020a/lib64/R/library"
QUESTION :
Is there a way to prevent .libPaths() from resolving the symbolic link /export/ to its full path?
I went ahead and installed the R package on our remote testing environment (system1) at /gpfs0/remote-test/export/apps/opt/monocle3/1.0.0. It works (at least I can load the library) on system1.
I then rsync'd it the installed packages to /gpfs0/export/apps/opt/monocle3/1.0.0 on system2 and it works there as well.
I did do some checking (i.e. find . -name "*.so" -print | xargs -I var grep -in remote-test var) of the shared libraries and the string remote-test was hard-baked into three of the shared libraries.
It appears that I got away with this this time (See user2554330's answer for why it may not work in the future). I was not hurt by any hard-baked paths as far as I can tell. In this instance, I could can move R libraries around without breaking things.