arpack @3.1.1 +openmpi or +mpich configure fails if mpi wasn't built with fortran wrappers

[dstrubbe (David Strubbe)]

The variants +openmpi or +mpich make the build fail if openmpi/mpich were not built with Fortran support, since configure cannot find (open)mpif77. We should use active_variants to make sure the dependency was built with Fortran support, and indeed it probably needs to be the same Fortran compiler as is being used for F77.

A more minor issue: building with MPI causes some PARPACK test programs to be installed.

Port arpack contains:
  /opt/local/bin/pcndrv1
  /opt/local/bin/pdndrv1
  /opt/local/bin/pdndrv3
  /opt/local/bin/pdsdrv1
  /opt/local/bin/psndrv3
  /opt/local/bin/pssdrv1
  /opt/local/bin/pzndrv1
  ...

By analogy to the ARPACK test program dnsimp, these should probably not be installed. They don't work anyway, for me at least, even though PARPACK works fine in an application.

$ pcndrv1     
dyld: lazy symbol binding failed: Symbol not found: _second_
  Referenced from: /opt/local/lib/libparpack.2.dylib
  Expected in: flat namespace

dyld: Symbol not found: _second_
  Referenced from: /opt/local/lib/libparpack.2.dylib
  Expected in: flat namespace

Trace/BPT trap: 5

Attached Portfile diff establishes active variants requirements and removes test programs from installation.

Also, it seems from livecheck that arpack 3.1.3 has been released, so I guess that could be updated in the port.

[mamoll (Mark Moll)]

Thanks! Committed in r106733. I tried to update the port, but get errors when trying to compile. Here are the Portfile changes:

Index: Portfile
===================================================================
--- Portfile	(revision 106733)
+++ Portfile	(working copy)
@@ -5,8 +5,7 @@
 PortGroup  active_variants 1.1
 
 name          arpack
-version       3.1.2
-revision      1
+version       3.1.3
 categories    math
 license       BSD
 platforms     darwin
@@ -16,13 +15,12 @@
     ARPACK is a collection of Fortran77 subroutines designed to solve large \
     scale eigenvalue problems. Parallel ARPACK (PARPACK) is included if built with an MPI variant.
 homepage            http://forge.scilab.org/index.php/p/arpack-ng
-master_sites        ${homepage}/downloads/497
-distfiles           get
-dist_subdir         ${name}/${version}
-checksums           md5     7644e234f219ec1a29849b6d7811a6b1 \
-                    sha1    f5453e2d576f131890ca023e1d853e18920f9c3c \
-                    rmd160  2c55eca384cc0a1aebacdef527f88426932bf57b
-worksrcdir          ${name}-ng_${version}
+master_sites        ${homepage}/downloads/get
+distfiles           arpack-ng-${version}.tar.gz
+checksums           md5     90ba42eae70b517ebdb72921cb4186df \
+                    sha1    c1ac96663916a4e11618e9557636ba1bd1a7b556 \
+                    rmd160  30a3b8a707417afeb3f8a794ee3aa0160fa3e745
+worksrcdir          ${name}-ng-${version}
 
 configure.args-append home=${worksrcpath} --disable-mpi
 # LDFLAGS needs to be defined here to avoid it having also a "-arch" option, considered illegal by gfortran

Perhaps you can make it work...

[cooljeanius (Eric Gallager)]

Cc Me!

[dstrubbe (David Strubbe)]

They did something funny to the build system for ARPACK 3.1.3. I submitted a query upstream: ​http://forge.scilab.org/index.php/p/arpack-ng/issues/1220/. We can just patch to undo it, but maybe they can give some insight into what is going on.

[dstrubbe (David Strubbe)]

I found workarounds to the 3.1.3 issues. See attached Portfile patch, which updates to 3.1.3. Basically, we need to use the '-l' style of linking for blas/lapack.

I removed g95 which no longer works with this version. Before, the linking happened with the C compiler, but now the Fortran one has to do it, and g95 won't accept the link options given by libtool in arpack.

Previously, you could select independently the Fortran compiler and the MPI implementation. However, we enforced that the MPI had to have been built with the corresponding compiler. In fact, doing that implies there is no purpose in specifying the Fortran compiler when using MPI, so I made openmpi and mpich variants on the same footing as the Fortran compilers, all conflicting. This could have been done in the 3.1.2 Portfile too, but it is necessary now for 3.1.3, because if we specify F77 with the Fortran compiler as we were doing, then that will be used to link, which will fail in PARPACK. We must give (open)mpif77 as F77 to make it work, in which case gfortran has no role to play any more. We must still enforce that some Fortran wrapper is present for the MPI ports, so I added that to the pre-fetch stage.

The gcc variants use 'configure.compiler' rather than setting F77 explicitly. This makes sure that compiler suite used also for C checks in the configure script.

[mamoll (Mark Moll)]

The patch looks good, but unfortunately I still get a compilation error:

libtool: link: /opt/local/bin/openmpif77 -dynamiclib  -o .libs/libparpack.2.dylib   -Wl,-force_load,../SRC/.libs/libarpacksrc.a -Wl,-force_load,../UTIL/.libs/libarpackutil.a -Wl,-force_load,../PARPACK/SRC/MPI/.libs/libparpacksrcmpi.a -Wl,-force_load,../PARPACK/UTIL/MPI/.libs/libparpackutilmpi.a  -lblas -llapack  -O2 -m64   -install_name  /opt/local/lib/libparpack.2.dylib -compatibility_version 3 -current_version 3.0 -Wl,-single_module
Undefined symbols for architecture x86_64:
  "_second_", referenced from:
      _psgetv0_ in libparpacksrcmpi.a(libparpacksrcmpi_la-psgetv0.o)
      _psnaitr_ in libparpacksrcmpi.a(libparpacksrcmpi_la-psnaitr.o)
      _psnapps_ in libparpacksrcmpi.a(libparpacksrcmpi_la-psnapps.o)
      _psnaup2_ in libparpacksrcmpi.a(libparpacksrcmpi_la-psnaup2.o)
      _psnaupd_ in libparpacksrcmpi.a(libparpacksrcmpi_la-psnaupd.o)
      _psneigh_ in libparpacksrcmpi.a(libparpacksrcmpi_la-psneigh.o)
      _psngets_ in libparpacksrcmpi.a(libparpacksrcmpi_la-psngets.o)
      ...
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [libparpack.la] Error 1

I am trying to install arpack +openmpi +accelerate.

[dstrubbe (David Strubbe)]

Odd. That build succeeds for me, and I have exactly the corresponding line in my log. What variant of openmpi are you using? I tried openmpi @1.7.1_0+gcc47.

[mamoll (Mark Moll)]

I have the same variant of openmpi installed. I also tried installing it with the previous version of arpack deactivated, so that that version wouldn't found at link time. I am on OS X 10.8.4 with the latest Xcode, MacPorts base and ports from svn. I have attached a tar ball with the build directory. Perhaps that can provide a clue.

[dstrubbe (David Strubbe)]

I figured out a way to reproduce: it works if atlas is installed, but not if isn't. I recall also that problems with the symbol 'second' are what I had reported about the PARPACK examples above too.

[dstrubbe (David Strubbe)]

I have reported the 'second' issue upstream, and made a patch to resolve it. Also, I added conflicts lists for openmpi and mpich, which should have been there before, and restored the g95 variant, since it will work provided we pass --disable-shared.

[mamoll (Mark Moll)]

Thanks for the patches. Committed in r107140.

[jmroot (Joshua Root)]

Do you really need to set LDFLAGS in configure.args rather than just clearing configure.ldflags?

[dstrubbe (David Strubbe)]

Yes: this is a hack obviously, but a workaround for problems with ld and/or libtool. Without the LDFLAGS, the directory from which to get blas and lapack is not specified and it will use the atlas ones instead.

Also, see attached patch to Portfile to move active_variants uses to pre-configure, as pointed out by larryv.

[larryv (Lawrence Velázquez)]

Replying to dstrubbe@…:

Yes: this is a hack obviously, but a workaround for problems with ld and/or libtool. Without the LDFLAGS, the directory from which to get blas and lapack is not specified and it will use the atlas ones instead.

Would this work?

configure.ldflags   {}

Also, see attached patch to Portfile to move active_variants uses to pre-configure, as pointed out by larryv.

I think mmoll fixed that in r107142, but you should check it against your patch.

[dstrubbe (David Strubbe)]

Oh ok, r107142 looks good to me too.

As I said, we need LDFLAGS to specify where the libraries are explicitly. The build will fail unless "/usr/lib/libblas.dylib /usr/lib/liblapack.dylib" is on the link line. It doesn't look like a reasonable construct, but is the only one of more combinations I tried that works, given some apparent bugs in ld and/or libtool. See the ARPACK issue I reported at ​​http://forge.scilab.org/index.php/p/arpack-ng/issues/1220/ for more details (as well as some useless discussion...)

[mamoll (Mark Moll)]

Using LDFLAGS has also been the only way for me to get things to work. It's not a particularly elegant solution, but the only one I found that worked.