Bug #2026

charm-6.8.2 breaks linking process of NAMD if it's patched with shared version of PLUMED

Added by viktor drobot 9 days ago. Updated 9 days ago.

Target version:
Start date:
Due date:
% Done:



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 ( and here ( 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 9 days 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:

            if [ -n "$POST_LANGUAGE" ]
                    POST_LIBRARIES="$POST_LIBRARIES $arg" 
                    PRE_LIBRARIES="$PRE_LIBRARIES $arg" 

then this bit substitutes in the lib_so path even if shared libraries were never built:
            # make sure to link against shared charm library if creating a shared object:
            case $FILE in
                    *.so|*.so.*|*.dylib) CHARM_SHARED=1 ;;
            [ ! -s $FILE ] && Abort "$FILE: file not recognized: File truncated" 

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.

#2 Updated by Jim Phillips 9 days ago

I think the best workaround on the plumed side would be to use PLUMED_LOAD="-L/path/to/plumed/lib -lplumed -ldl" rather than listing /path/to/plumed/lib/ explicitly as a file.

Also available in: Atom PDF