Refactor: Create autoconf variables for MPI, to run with other MPI implementations

[gc00]

Hi @rohgarg,

This is a first attempt at making MANA portable across different MPI implementations.

Look at DMTCP_ROOT/configure-mana for an example of how to use it. After configuring, it will then use the Makefile variables found in DMTCP_ROOT/contrib/mpi-proxy-split/Makefile_config.

I tested this with MPICH. The configure-mana file is set for my MPICH build on login (CentOS).

Mostly, I can do 'make' in contrib/mpi-proxy-split. But in lower-half, 'make' fails to compile the lh_proxy executable, with the error message:
/usr/bin/ld: cannot find -lxml2
In my next debugging session, I'll look for why it needs libxml2.a. Apparently, mpicc translates -lmpi -lrt into -lmpi -lm -lxml2 -lpthread -lrt. I'm not sure why. Looking at sh -x mpicc ..., I don't see an -lxml2 when compiling simple MPI programs in the test subdirectory.

IN THIS UPDATED PR, THE BUG BELOW HAS BEEN FIXED NOW BY THE SECOND COMMIT:
What you'll see is that contrib/mpi-proxy-split/mpi-wrappers/mpi_dummy.c fails to compile, because the mpi.h supplied by MPICH is incompatible with our assumed mpi.h in that file. Maybe you can diagnose this further, @rohgarg. Feel free to extend this branch and merge it, if you can figure out mpi_dummy.c. Developing on a local machine will be faster than developing on Cori, where 'srun' can take a long time to start up.

Also, as a small side note, I saw that test/autotest_config.py was placed under git version control. This seems to be a mistake, since we already have test/autotest_config.py.in. But you know your intentions better than me. Could you also take a look at that?

[rohgarg]

The configure-mana file is set for my MPICH build on login (CentOS). What you'll see is that contrib/mpi-proxy-split/mpi-wrappers/mpi_dummy.c fails to compile, because the mpi.h supplied by MPICH is incompatible with our assumed mpi.h in that file.

I'm aware of the issue, @gc00. The problem occurs because some of the MPI functions have a slightly different prototype in the two implementations, which is strange. :-) I have had to manually edit the wrapper prototypes in the plugin to make it work so far. Anyway, I will try to create a more general fix to make it work.

[rohgarg]

@gc00: I checked my build of mpich-3.3.2 on a CentOS7 machine. I don't have libxml2 installed. I configured and built mpich with the following options

$ ./configure --enable-g=dbg --prefix=/home/rohgarg/sws

Here's what the config.log says:

configure:38772: checking for LIBXML2
configure:38780: $PKG_CONFIG --exists --silence-errors "libxml-2.0"
configure:38783: $? = 1
configure:38799: $PKG_CONFIG --exists --silence-errors "libxml-2.0"
configure:38802: $? = 1
No package 'libxml-2.0' found
12265 configure:38832: result: no

Th next code snippet is from the header file (src/include/mpichconf.h) it generates.

/* Define to 1 if you have the `libxml2' library. */
/* #undef HWLOC_HAVE_LIBXML2 */

I was looking at the options used by mpicc while trying to link the lower half binary. Here's the full command line:

/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/collect2 --build-id --no-add-needed --hash-style=gnu -m elf_x86_64 -static -o lh_proxy /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtbeginT.o -L/home/rohgarg/sws/lib -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../.. -Ttext-segment 0xE000000 --wrap __munmap --wrap shmat --wrap shmget lh_proxy.o libproxy.a -lmpi -lrt -lpthread -lc libproxy.a -rpath /home/rohgarg/sws/lib --enable-new-dtags -lmpi -lm -lpthread -lrt --start-group -lgcc -lgcc_eh -lc --end-group /usr/lib/gcc/x86_64-redhat-linux/4.8.5/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crtn.o

[rohgarg]

@gc00: I looked at mpich's source more carefully. It's the hwloc library (a dependency of mpich, and shipped along with the mpich source) that requires libxml2. However, hwloc does detect if libxml2 is not available on the system and can be built with/without libxml2 support.

On my CentOS7 system, with no libxml2 installed, it indeed builds without libxml2.

/home/rohgarg/sws/mpich-3.3.2/src/hwloc/hwloc $ ls topology-xml*
topology-xml.c  topology-xml.lo  topology-xml.o  topology-xml-libxml.c  topology-xml-nolibxml.c  topology-xml-nolibxml.lo  topology-xml-nolibxml.o

Note that only the *-nolibxml versions of the source files are compiled. The *-libxml versions are not compiled, since the configure script did not find any libxml2 on the system (see my comment above).