#39365 closed defect (fixed)
arpack @3.1.1 +openmpi or +mpich configure fails if mpi wasn't built with fortran wrappers
Reported by: | dstrubbe (David Strubbe) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.1.3 |
Keywords: | haspatch | Cc: | mamoll (Mark Moll), cooljeanius (Eric Gallager) |
Port: | arpack |
Description
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.
Attachments (6)
Change History (21)
Changed 11 years ago by dstrubbe (David Strubbe)
Attachment: | Portfile-arpack.diff added |
---|
comment:1 Changed 11 years ago by mamoll (Mark Moll)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 Changed 11 years ago by 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.
comment:4 Changed 11 years ago by dstrubbe (David Strubbe)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
Changed 11 years ago by dstrubbe (David Strubbe)
Attachment: | Portfile-arpack.2.diff added |
---|
comment:5 Changed 11 years ago by 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.
comment:6 Changed 11 years ago by 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.
comment:7 Changed 11 years ago by 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.
Changed 11 years ago by mamoll (Mark Moll)
Attachment: | arpack-ng-3.1.3-build.tgz added |
---|
comment:8 Changed 11 years ago by 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.
comment:9 Changed 11 years ago by 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.
Changed 11 years ago by dstrubbe (David Strubbe)
Attachment: | Portfile-arpack.3.diff added |
---|
Changed 11 years ago by dstrubbe (David Strubbe)
Attachment: | patch-UTIL-second_NONE.f.diff added |
---|
comment:10 Changed 11 years ago by mamoll (Mark Moll)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Thanks for the patches. Committed in r107140.
comment:11 Changed 11 years ago by jmroot (Joshua Root)
Do you really need to set LDFLAGS in configure.args rather than just clearing configure.ldflags?
comment:12 follow-up: 13 Changed 11 years ago by 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.
Changed 11 years ago by dstrubbe (David Strubbe)
Attachment: | Portfile-arpack.4.diff added |
---|
comment:13 Changed 11 years ago by 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.
comment:14 Changed 11 years ago by 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...)
comment:15 Changed 11 years ago by 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.
Thanks! Committed in r106733. I tried to update the port, but get errors when trying to compile. Here are the Portfile changes:
Perhaps you can make it work...