libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MPI wrapper not being used for linking shared libraries


From: Paul T. Bauman
Subject: MPI wrapper not being used for linking shared libraries
Date: Thu, 21 Apr 2016 09:38:39 -0400

Greetings,

A very related question was asked about 4 years ago (https://lists.gnu.org/archive/html/libtool/2012-05/msg00002.html), but I figured a new thread would be preferred (sorry if it's not). I could not find other queries along this line in the mailing list archive.

libtool is not respecting the use of MPI wrappers (mpicc, mpicxx, etc) for linking shared libraries. For example, using a vanilla install of MPICH:

$ uname -sr
Linux 2.6.32-573.18.1.el6.x86_64

$ libtool --version
libtool (GNU libtool) 2.4.6

$ cat foo.c
int foo()
{ return 1; }

$ cat bar.c
double bar()
{ return 1.0; }

$ libtool --tag=CC --mode=compile mpicc -c foo.c
libtool: compile:  mpicc -c foo.c  -fPIC -DPIC -o .libs/foo.o
libtool: compile:  mpicc -c foo.c -o foo.o >/dev/null 2>&1


$ libtool --tag=CC --mode=compile mpicc -c bar.c
libtool: compile:  mpicc -c bar.c  -fPIC -DPIC -o .libs/bar.o
libtool: compile:  mpicc -c bar.c -o bar.o >/dev/null 2>&1


$ libtool --tag=CC --mode=link mpicc -o libtest.la foo.lo bar.lo -rpath /usr/local/lib -lm
libtool: link: rm -fr  .libs/libtest.a .libs/libtest.la .libs/libtest.lai .libs/libtest.so .libs/libtest.so.0 .libs/libtest.so.0.0.0
libtool: link: gcc -shared  -fPIC -DPIC  .libs/foo.o .libs/bar.o   -lm    -Wl,-soname -Wl,libtest.so.0 -o .libs/libtest.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libtest.so.0" && ln -s "libtest.so.0.0.0" "libtest.so.0")
libtool: link: (cd ".libs" && rm -f "libtest.so" && ln -s "libtest.so.0.0.0" "libtest.so")
libtool: link: ar cru .libs/libtest.a  foo.o bar.o
libtool: link: ranlib .libs/libtest.a
libtool: link: ( cd ".libs" && rm -f "libtest.la" && ln -s "../libtest.la" "libtest.la" )

Above, gcc was used during the generation of .libs/libtest.so.0.0.0 as opposed to the mpicc that was given to libtool.

Interestingly, it does not do this for linking programs, but rather uses the MPI wrapper:

$ cat mpihw.c
#include <mpi.h>
#include <stdio.h>

int main(int argc, char** argv) {
    // Initialize the MPI environment
    MPI_Init(NULL, NULL);

    // Get the number of processes
    int world_size;
    MPI_Comm_size(MPI_COMM_WORLD, &world_size);

    // Get the rank of the process
    int world_rank;
    MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);

    // Get the name of the processor
    char processor_name[MPI_MAX_PROCESSOR_NAME];
    int name_len;
    MPI_Get_processor_name(processor_name, &name_len);

    // Print off a hello world message
    printf("Hello world from processor %s, rank %d"
           " out of %d processors\n",
           processor_name, world_rank, world_size);

    // Finalize the MPI environment.
    MPI_Finalize();
}

$ libtool --tag=CC --mode=compile mpicc -c mpihw.c
libtool: compile:  mpicc -c mpihw.c  -fPIC -DPIC -o .libs/mpihw.o
libtool: compile:  mpicc -c mpihw.c -o mpihw.o >/dev/null 2>&

$ libtool --tag=CC --mode=link mpicc -o a.out mpihw.lo
libtool: link: mpicc -o a.out .libs/mpihw.o


This reason I want this behavior is that, when using the MPI wrapper, the lib path for the MPI installation is automatically used/available during the linking step so that I do not need to specify -L/path/to/mpi -lmpich (or whatever). Obviously, we could update our build system to include those paths at linking time, but I would prefer to be able to use this feature of the wrappers, particularly when building libraries/applications that "inherit" MPI from other libraries that do not make available the MPI lib paths they used (because they are using the MPI wrappers to link).

Unfortunately, I'm not familiar with the libtool code and my brief foray into the libtool.m4 was fruitless. Is the behavior in the example the expected behavior? Is there a way for me to override this behavior, i.e. force the use of mpicc when linking shared libraries? I couldn't find documentation or examples to this effect through a fair amount of Google searching. If this is not the expected behavior, I'm happy to try and cook up a patch with some guidance.

Thank you for your time and efforts.

Best,

Paul

reply via email to

[Prev in Thread] Current Thread [Next in Thread]