Bug in libmesh libtool script affecting Fortran and shared libs

[jwpeterson]

We have some folks trying to use the libmesh-generated libtool script to link Fortran libraries and executables on Linux. It may be the first time someone has tried this (?) and therefore we've never noticed the issue before, but I think I've tracked it down to the "postdeps" line in the "FC" section of $LIBMESH_DIR/contrib/bin/libtool, which I've pasted below.

postdeps="-L/opt/packages/mpich/mpich-3.0.2/gcc-opt/lib -lmpichf90
-lmpich -lopa -lmpl -lrt -lpthread -l -l
-L/opt/packages/mpich/mpich-3.0.2/gcc-opt/lib
-L/usr/lib/gcc/x86_64-linux-gnu/4.6
-L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib
-L/opt/packages/tbb/lib/intel64/cc4.1.0_libc2.4_kernel2.6.16.21
-L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. -lmpichf90 -lmpich -lopa
-lmpl -lrt -lpthread -lgfortran -lm -lgcc_s -lquadmath -lm -lgcc_s -lc
-lgcc_s"

As you can see, there are two naked "-l" flags in this variable, and whenever libtool tries to use it to link a Fortran shared library, it obviously fails.

Unfortunately I don't know where to go from here in debugging the problem... note that it doesn't seem to affect Macs: the postdeps line is just blank for that OS. Also, if I hand edit the libtool script file and remove those -l's things seem to work fine.

[jwpeterson]

This thread: http://lists.gnu.org/archive/html/bug-libtool/2012-03/msg00004.html seems to shed some light on the situation. If you run mpif90 -shared -g -v it emits the following:

$ mpif90 -shared -g -v
mpif90 for MPICH version 3.0.2
Driving: gfortran -shared -g -v -I/opt/packages/mpich/mpich-3.0.2/gcc-opt/include -I/opt/packages/mpich/mpich-3.0.2/gcc-opt/include -L/opt/packages/mpich/mpich-3.0.2/gcc-opt/lib -lmpichf90 
-Wl,-rpath -Wl,/opt/packages/mpich/mpich-3.0.2/gcc-opt/lib -lmpich -lopa -lmpl -lrt -lpthread -l gfortran -l m -shared-libgcc

on the last line, you can see the spaces in "-l gfortran" and "-l m" which is what's hosing libtool. It looks like no one ever responded to the guy though...

[benkirk]

Hmm... Maybe it should get pointed out to the mpich guys?

-Ben

On Jun 18, 2013, at 10:53 PM, "jwpeterson" <notifications@github.commailto:notifications@github.com> wrote:

This thread: http://lists.gnu.org/archive/html/bug-libtool/2012-03/msg00004.html seems to shed some light on the situation. If you run mpif90 -shared -g -v it emits the following:

$ mpif90 -shared -g -v
mpif90 for MPICH version 3.0.2
Driving: gfortran -shared -g -v -I/opt/packages/mpich/mpich-3.0.2/gcc-opt/include -I/opt/packages/mpich/mpich-3.0.2/gcc-opt/include -L/opt/packages/mpich/mpich-3.0.2/gcc-opt/lib -lmpichf90
-Wl,-rpath -Wl,/opt/packages/mpich/mpich-3.0.2/gcc-opt/lib -lmpich -lopa -lmpl -lrt -lpthread -l gfortran -l m -shared-libgcc

on the last line, you can see the spaces in "-l gfortran" and "-l m" which is what's hosing libtool. It looks like no one ever responded to the guy though...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/107#issuecomment-19641285.

[jwpeterson]

You're right, it does seem to be mpich's mpif90 wrapper which causes this problem. If I just run gfortran -shared -v it doesn't print that weird "Driving:" line at all. I don't have an OpenMPI stack handy on Linux at the moment, but I bet it doesn't have that problem either.

[jwpeterson]

Since it's unlikely mpich will change their compiler wrappers any time soon, or that libtool will do some internal parsing of what compilers spit back to it, my thought was to just fix up the libtool script during the 'make install' process. Looking at Makefile.am, it seems like the "install-data-hook" target might be the appropriate place to do this. So.

1. Does that sound right?
2. Can we edit Makefile.am by hand?
3. If you edit Makefile.am, do you have to re-bootstrap each time?
   Thanks!

[benkirk]

On Jun 24, 2013, at 10:30 AM, "jwpeterson" notifications@github.com wrote:

1. Does that sound right?

Yes. Such hooks are provided for arbitrary user-level mucking around, which sounds appropriate for this need.

1. Can we edit Makefile.am by hand?

Sure.

1. If you edit Makefile.am, do you have to re-bootstrap each time?

No. If you edit Makefile.am and the type make, it should do the right thing - e.g. regenerate Makefile.in and Makefile.

-Ben

[jwpeterson]

@benkirk could you take a look at this patch and see if it's OK? It works for me on the one linux system I have which demonstrates the problem, mostly I wonder if $(exec_prefix) is OK to use or should I prefer $(DESTDIR) instead?