Project

General

Profile

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.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11/05/2018
Due date:
% Done:

0%


Description

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

History

#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:

    -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.

#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/libplumed.so explicitly as a file.

Also available in: Atom PDF