Open drwells opened 2 years ago
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?
My description wasn't that clear. Here is exactly what I saw:
libmesh_opt.so
itselflibmesh_opt.so
)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?
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.
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@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 ~]$
I first noticed this in the libMesh release candidate and traced the issue back here.
I have a compiler wrapper script
cxx-shim.sh
:configuring TIMPI to use this like
results in a weird libtool problem:
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.