On Mar 31, 2009, at 4:21 PM, Gus Correa wrote:
Please, correct my argument below if I am wrong.
I am not sure yet if the problem is caused by libtool,
because somehow it was not present in OpenMPI 1.2.8.
Just as a comparison, the libtool commands on 1.2.8 and 1.3 are very
similar, although 1.2.8 builds right, and 1.3 breaks.
The libtool commands differ in that 1.3 inserts ../../../ompi/
libmpi.la
on the list of libraries to be linked to, whereas in 1.2.8
../../../ompi/libmpi.la is not there.
We did specifically add the following in the build process in v1.3:
libmpi_f90_la_LIBADD = $(top_builddir)/ompi/libmpi.la
which means that libmpi_f90 will link against libmpi. That is the
source of this ickyness. Here's the commit where I put this change in
to Open MPI:
https://svn.open-mpi.org/trac/ompi/changeset/19040
IIRC, the reason is that libmpi_f90 depends on libmpi (i.e., it calls
functions in libmpi). If nothing else, it's the Right Thing To Do to
link in a dependent library. But also to setup automatic rpath's
properly, it is best to actually create libmpi_f90 with an explicit
dependency (which turns into an implicit dependency later). Rpath
isn't a huge deal here because both libmpi and libmpi_f90 should be
installed in the same directory, but it's the principle of the
thing... Additionally, it allows people to be lazy and do something
like:
gfortran my_mpi_application.f90 -lmpi_f90
and that pulls in the rest of the libraries because of the implicit
dependencies. I think there were other reasons to do the explicit/
implicit dependencies (e.g., look at ldd output and you can tell what
libs will be pulled in, etc.), but I don't remember them all off the
top of my head. :-(
> I can think of two workarounds for you (one significantly less
icky than
> the other):
>
> 1. Use pgcc, pgCC, pgf77, and pgf90 to build Open MPI. If you
have no
> C++ MPI code, the resulting Open MPI build *should* be compatible
with
> your C + Fortran code.
Yes, this one, using only PGI compilers, was built already.
Our concern is that some codes seem to rely on gcc as the underlying
C compiler.
Hence the need for the hybrid libraries.
Ok, bummer.
> 2. Instead of using the "real" pgf77/pgf90, put pgf77/pgf90 scripts
> early in your PATH that simply strip out -pthread from the argv
and then
> invoke the real/underlying pgf77/pgf90 compilers. This is pretty
icky,
> but it should work...
Here is the "fake pgf90" script:
#! /bin/bash
newargs=`echo $@ | sed s/-pthread//g -`
echo "/real/path/to/bin/pgf90 $newargs"
/real/path/to/bin/pgf90 $newargs
exit
Then I changed the path to get this script ahead of the real pgf90,
did make distclean, removed old subdirectories,
configured again, did make again ... and ...
It works!
Ugly, but functional! :)
While a final fix for the configure/libtool issue is in the works,
this is fine.
Many thanks.
Glad we got it working, but I agree that it is significantly ugly. :-)
Question:
The output of ompi_info --config shows that the absolute path to the
"fake pgf90" script was recorded by OpenMPI.
Will OpenMPI mpif90 hardwire this absolute path, or will it
search the user $PATH variable for the real mpif90 first?
Eww -- good point. I believe that those absolute pathnames are *only*
recorded for ompi_info output so that you can know which compiler was
used to build Open MPI after the fact. The relative names are stored
for use in the wrapper compilers. However, the wrapper compiler
arguments are fully customizable -- you might want to remove the
"fake" compilers after the fact. See this FAQ entry for details:
http://www.open-mpi.org/faq/?category=mpi-apps#override-wrappers-after-v1.0
--
Jeff Squyres
Cisco Systems
