libtool link failure when using compiler wrappers

[drwells]

I first noticed this in the libMesh release candidate and traced the issue back here.

I have a compiler wrapper script cxx-shim.sh:

#!/bin/sh

ccache mpic++ "$@"

configuring TIMPI to use this like

#!/bin/bash

declare -x CC="/home/drwells/Documents/Code/Shell/autoibamr/c-shim.sh"
declare -x CXX="/home/drwells/Documents/Code/Shell/autoibamr/cxx-shim.sh"

mkdir -p build
cd build
../configure

make -j4 V=1

results in a weird libtool problem:

libtool: link: /home/drwells/Documents/Code/Shell/autoibamr/cxx-shim.sh -o .libs/timpi_version-opt apps/version.o  ./.libs/libtimpi_opt.so -rpath /usr/local/lib
g++: error: unrecognized command-line option '-rpath'
make[1]: *** [Makefile:954: timpi_version-opt] Error 1
make[1]: *** Waiting for unfinished jobs....
libtool: warning: '-version-info' is ignored for programs
libtool: link: /home/drwells/Documents/Code/Shell/autoibamr/cxx-shim.sh -o .libs/timpi_version-dbg apps/version.o  ./.libs/libtimpi_dbg.so -rpath /usr/local/lib
g++: error: unrecognized command-line option '-rpath'
make[1]: *** [Makefile:942: timpi_version-dbg] Error 1
libtool: warning: '-version-info' is ignored for programs
libtool: link: /home/drwells/Documents/Code/Shell/autoibamr/cxx-shim.sh -o .libs/timpi_version-devel apps/version.o  ./.libs/libtimpi_devel.so -rpath /usr/local/lib
g++: error: unrecognized command-line option '-rpath'
make[1]: *** [Makefile:946: timpi_version-devel] Error 1

i.e., the compiler wrapper script is treated as a linker instead of as a C++ compiler and the preceding -Wl, flag is not present.

It looks like libMesh 1.5.x had a similar bug when I went back and checked - I see the same failure there when trying to link libmesh_opt.so but I don't see it in the 1.7 release candidate for libMesh itself.

[jwpeterson]

I first noticed this in the libMesh release candidate

I don't see it in the 1.7 release candidate for libMesh itself.

So you first noticed the issue in an older release candidate, and it's not in 1.7, is that correct?

[drwells]

My description wasn't that clear. Here is exactly what I saw:

1. I see a similar libtool problem with libMesh 1.5.0 that occurs when linking libmesh_opt.so itself
2. I do not see a similar problem with libMesh 1.7.0-rc3 (when linking libmesh_opt.so)
3. I see this problem with whatever version of timpi is in the 1.7.0-rc3 release candidate and also the master branch

[jwpeterson]

Hmm... I guess it's not clear to me where that naked -rpath is coming from? I see -Wl,-rpath,/foo/bar/lib in lots of our generated Makefiles, but always preceded by the -Wl. So is something stripping off the -Wl, part?

[drwells]

I have absolutely no idea. It is super weird that this problem only shows up when I use my shell script shims for the compilers.

I was hoping you might know since the same problem used to exist in libMesh but was fixed at some point recently.

[jwpeterson]

OK, unfortunately it's not something I remember fixing. We had an issue once where an MPI compiler wrapper was generating bad commands (in that case it was "-l gfortran -l m" that broke things). What does your mpic++ -show print?

[drwells]

drwells@learch ~]$ mpic++ -show
g++ -pthread -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib/openmpi -Wl,--enable-new-dtags -L/usr/lib/openmpi -lmpi_cxx -lmpi
[drwells@learch ~]$