Opened 12 years ago

Closed 11 years ago

#38065 closed defect (fixed)

openmpi @1.6.3_0+gcc47+valgrind -- header locations not self-consistent

Reported by: beany_kelly@… Owned by: mww@…
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: eborisch (Eric A. Borisch)
Port: openmpi

Description (last modified by larryv (Lawrence Velázquez))

I have a Mountain Lion system (10.8.2) with an up-to-date MacPorts installation. I've installed OpenMPI as above (+gcc47 +valgrind), but I'm having trouble compiling parallel code with it, because the headers aren't where the system expects. Here's a sample error from the compiler:

/opt/local/include/mpi.h:2087:41: fatal error: openmpi/ompi/mpi/cxx/mpicxx.h: No such file or directory

The problem is that apart from mpi.h itself, all the headers are buried deep down, one layer feeper than mpi.h indicates. For instance, mpicxx.h is *actually* in (relative to /opt/local/include):

openmpi/openmpi/ompi/mpi/cxx/mpicxx.h

I don't know why so much nesting is needed to begin with, but it looks like the path on line 2087 of mpi.h is out by one "openmpi/".

I can fix this path by hand, of course, but then the same error crops up again with another path ...

I've tried a clean port uninstall and new installation, but no change.

Change History (7)

comment:1 Changed 12 years ago by larryv (Lawrence Velázquez)

Description: modified (diff)
Keywords: headers removed
Owner: changed from macports-tickets@… to mww@…

Thanks for the ticket. In the future, please Cc relevant port maintainers and use WikiFormatting to format the description.

comment:2 Changed 12 years ago by eborisch (Eric A. Borisch)

Are you using the openmpicc / openmpicxx (may not be exact names) compiler wrappers? They should set the include paths automatically (likely have -I/opt/local/include/openmpi) so things work. (I haven't had a chance to check that in this particular instance, just prior experience.)

The wrappers are the best way to use mpich or openmpi -- you dan't have to worry about if there are internal changes (library names, for example) from version to version.

comment:3 Changed 12 years ago by eborisch (Eric A. Borisch)

Cc: eborisch@… added

Cc Me!

comment:4 Changed 12 years ago by beany_kelly@…

Hi & thanks. Actually, I wasn't using the wrappers --- though I had thought I was. Now that I try to use them, I'm not getting the header issues any more, but things still aren't compiling. The wrappers aren't reporting what I expect, either:

openmpicc --version

yields the following:

Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix

This seems strange to me, because I requested openmpi +gcc47, as noted above. Why would it be reporting Clang? The which and locate commands don't show any other instances of openmpicc on my system.

comment:5 Changed 12 years ago by eborisch (Eric A. Borisch)

The openmpi port (as port variants openmpi describes) takes the approach of using the gcc version you select to set the fortran compiler, but not the c/c++ compiler. There's been some discussion on this in the past. mpich uses the requested compilers for everything.

You can use mpich if you're interested in MPI with a particular gcc/g++ (sudo port install mpich +gcc47)

comment:6 Changed 12 years ago by beany_kelly@…

Hi eborisch, and thanks for the information.

Wow; I didn't realise I had no control over the C/C++ compilers with the MacPorts OpenMPI installation. This mixed-compiler approach seems bizarre to me. I'd appreciate your linking to the past discussion, as I can't find it using the Ticket Search box.

In the mean time, I'll try MPICH instead, as per your suggestion.

Last edited 12 years ago by beany_kelly@… (previous) (diff)

comment:7 Changed 11 years ago by seanfarley (Sean Farley)

Resolution: fixed
Status: newclosed

This should be fixed with the changes I made to the OpenMPI portfile.

Note: See TracTickets for help on using tickets.