charm-6.8.2 breaks linking process of NAMD if it's patched with shared version of PLUMED
Hello, in our computational group we're using NAMD with PLUMED patch. Earlier we've been using NAMD-2.12 + charm-6.7.1 and patching with PLUMED in shared mode worked perfectly. Now we're trying to move for NAMD-2.13 + charm-6.8.2 and experiencing some troubles. Ahile compiling without PLUMED patch goes fine that isn't true for patched version.
You could find some detailed investigations (logs and listings) here (https://github.com/plumed/plumed2/pull/404) and here (https://github.com/plumed/plumed2/issues/406). To summarize: applying PLUMED patch adds $(PLUMED_LOAD) variable to the NAMD's Makefile and this is forces charmc (?) from charm-6.8.2 package to rebuild linking line and library search from .rootdir/charm-6.8.2/multicore-linux64/bin/../lib moves to the .rootdir/charm-6.8.2/multicore-linux64/lib_so directory. And of course during classic building of charm-6.8.2 (in static mode) there are no files in lib_so directory so the final linking steps of NAMD binaries fails. If I manually rebuild charm-6.8.2 with --build-shared option then I'm able to locate *.so files in lib_so and then NAMD building process completes properly (almost: there are some warnings after linking namd2 binary).
This is not the case if I patch NAMD with static-mode PLUMED - linking with static charm-6.8.2 completes just fine. So there are some problem appeared from the 6.7.1 version and we're not able to fix it by ourselves. So we need your help
#1 Updated by Jim Phillips 2 months ago
Here is what I think is going on. Plumed adds a .so file to the charmc link line. This bit in charmc ignores it:
-l*|*.a) if [ -n "$POST_LANGUAGE" ] then POST_LIBRARIES="$POST_LIBRARIES $arg" else PRE_LIBRARIES="$PRE_LIBRARIES $arg" fi INPUT_GIVEN="1" ;;
then this bit substitutes in the lib_so path even if shared libraries were never built:
*.o|*.so|*.so.*|*.sl|*.a|*.dylib|*.co) # make sure to link against shared charm library if creating a shared object: case $FILE in *.so|*.so.*|*.dylib) CHARM_SHARED=1 ;; esac [ ! -s $FILE ] && Abort "$FILE: file not recognized: File truncated" OBJECTFILES="$OBJECTFILES $FILE" ;;
I think adding "*.so|*.so.*|*.dylib" to the conditions for the POST_LIBRARIES might fix this, or simply remove the CHARM_SHARED=1 bit because explicitly linking against a dynamic library doesn't imply that the Charm++ shared libraries are needed.