Error when patching plumed (v2.9.1) to Gromacs 23.5
zhongxiang117 opened this issue · 6 comments
As a report, since this is caused by the new version of Plumed and Gromacs, I opened a new issue.
I downloaded the least version of plumed-v2.9.1, tried to patch Gromacs 2023.5, failed with the same error like #981, and solved by the same solution mentioned below by using version of git checkout fff0fa526. Thus there must be some hidden problems in codes.
Besides, there are one addition problem. If I compile plumed into a non-standard path (achieved by using export DESTDIR=mydir; make), after patch, in Gromacs root folder, there will be three plumed related files (symbolic link) added.
Plumed.cmake # symbolic link, to my custom location, Good
Plumed.inc # symbolic link, to my custom location, Good
Plumed.h # symbolic link, to standard location, Error!
Nonetheless, in whatever situations, these three files should be created at runtime patching, relative to the path where the plumed patch executes, not to its compiled paths.
Regarding this I think you are right, I reopened issue #981
Regarding this I think you are not expected to use DESTDIR to change the location. You should use --prefix /path. DESTDIR is to temporarily place the installed version in a different root directory for staging. This allows for instance to do make install without root permission, pack the installation directory in a single zip file, then unpack it to the correct prefix with root permissions.
I close this issue now, please reopen it if the answer is not clear. Thanks for reporting!
Hello @GiovanniBussi, thanks for your work!
For my second report of compilation path, I surely know how does DESTDIR work, and it is not a standard way to install package. But, I do not think it is a proper way to "hard-coded" it, I mean by using absolute path to create symbolic link, inside the source codes. As I mentioned, the files used for patching should be resolved during runtime execution, it should not depend on pre-configrautions where --prefix specifies.
I am not sure what's special with files used during patching.
Unfortunately we need to hard code paths for other reasons. It might be possible to strip down the absolute path form our dynamic library using dladdr (but it is not 100% supported) and some bash trick in our scripts. There are a couple of places however where I think we cannot, namely:
- on MacOs, libraries should contain an install name which is an absolute path
- when using a plumed linked as static library (libplumed.a), we have to know where plumed was installed so as to access its configuration files
Overall, since there are a few places where we need to store absolute paths, I don't see the point of making an effort to remove them in all other places. But, if you want to suggest a modification to the patch script that makes these paths computed at runtime I am happy to review it.
Thanks
Got that, thanks for your detail explanations. I will try to modify patch script to create a new modification.
Here are more additions, I'm not saying by dynamically resolving all those things, they can be actually defined before program executes. For example, when I use Plumed, the environment variable PLUMED_ROOT has to be predefined, to tell where the libplumed.a is, and this path should also be added to LD_LIBRARY_PATH, to find where libplumed.so is.
For example, there are some variables can be used before running plumed.
PLUMED_ROOT # defines the root of the program, as it does
PLUMED_BIN # defines where the binary
PLUMED_INCLUDE # defines includes
PLUMED_LIB # defines libraries
The paths omitted can be referenced from PLUMED_ROOT and it is mandatory, e.g. if PLUMEND_LIB is missing, it can be got by $PLUMED_ROOT/lib, similarly for PLUMED_INCLUDE can be got by $PLUMED_ROOT/include, and etc.
In this way, it has appealing advantages. By compiling and "installing" package once, all needed files/libraries are stored in one new folder, then user can move or rename this folder to everywhere inside this specific OS (happens when cleaning/changing disks, or compiling different versions, or distributing to different users in supercomputer but not with root privileges), plumed can be executed as long as PLUMED_ROOT is correctly defined and all its objects are intact.
While since it needs lots of work and considerations, maybe I am over optimistic, thank you!
Hello @GiovanniBussi, I have created a PR on environment variables, #1088, please have a check on it, thanks!