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
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
