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

[pplimport]

Original author: viktor drobot Original issue: https://charm.cs.illinois.edu/redmine/issues/2026

---

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

[jcphill]

Original date: 2018-11-05 22:56:30

---

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.

[jcphill]

Original date: 2018-11-05 23:05:05

---

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.

[jcphill]

Original date: 2019-01-04 20:06:16

---

Ping.

[evan-charmworks]

Original date: 2019-01-04 21:39:08

---

How's this? https://charm.cs.illinois.edu/gerrit/c/charm/+/4884 https://github.com/UIUC-PPL/charm/commit/baefaf8fa34db6d79fe2f4ce0cd9fd7a44ea20de

[evan-charmworks]

Original date: 2019-01-07 20:16:20

---

Any confirmation from upstream about whether my patch resolves the issue?