new mpich +gcc47 uses clang

[beany_kelly@…]

Hi. I don't know if this really counts as a defect, but it's making life harder for me.

Back in February (ticket #38065), I encountered problems with OpenMPI that were related to its use of clang for the C/C++ parts, instead of gcc/g++ (Fortran stayed GNU).

At the end of this, I moved to MPICH precisely because I could avoid clang. Now I find that my recently upgraded "mpich +gcc47" (on Mountain Lion) is now clang-ified. Is there no way of avoiding it?

I see that the *option* of bundling the clang version was discussed in ticket #39428, but in the last comment (8 weeks ago), it seemed merely to be a suggestion.

[jeremyhu (Jeremy Huddleston Sequoia)]

Discussion on macports-dev recently points to this becoming multiple subports. For example, mpich-gcc47 will be built by clang and use gcc47.

[beany_kelly@…]

Replying to jeremyhu@…:

Discussion on macports-dev recently points to this becoming multiple subports. For example, mpich-gcc47 will be built by clang and use gcc47.

Hi Jeremy. I'm not sure I understand what you mean by "use gcc47". This is what I see right now:

$ /opt/local/bin/mpicc --version
Apple LLVM version 4.2 (clang-425.0.27) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix

$ /opt/local/bin/mpif90 --version
GNU Fortran (MacPorts gcc47 4.7.3_2) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

So it's using gcc-47 for the Fortran parts, but Clang for C/C++. Are you saying this may (or will) revert to gcc-47 for all wrapped compilers?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to beany_kelly@…:

Replying to jeremyhu@…:

Discussion on macports-dev recently points to this becoming multiple subports. For example, mpich-gcc47 will be built by clang and use gcc47.

Hi Jeremy. I'm not sure I understand what you mean by "use gcc47". This is what I see right now:

So it's using gcc-47 for the Fortran parts, but Clang for C/C++. Are you saying this may (or will) revert to gcc-47 for all wrapped compilers?

Yes, the mpich-gcc47 port will use gcc47, the mpich-gcc48 port will use gcc48, etc. For all wrappers.

I assume we'll likely keep mpich using clang and clang++ as that is the sane default, but users like you want other options as well.

[beany_kelly@…]

Thanks, Jeremy. I agree that clang is a sensible default, but having an all-GCC option is welcome (as is having "gcc47" et al mean what they sound like).

[eborisch (Eric A. Borisch)]

I haven't had a chance to get back to this; perhaps this weekend. I want to move over applications to depend on the new mpicc-mp and friends before merging the changes back into trunk.

If you want to try out the new portfiles (mpich (1) and mpich_select (2)) the links are below.

For the record, here's how I described them on the mailing list:

I've put (in a separate branch [1]) changes in place to provide
mpich-default (which creates mpicc-mp, mpicxx-mp, and mpifNN-mp by
default) as well as a number of mpich-COMPILER ports to be installed
side-by-side, along with a mpich_select port to facilitate changing
what mpicc/mpicxx/mpifNN point to for the user. I would (assuming
people are OK with this approach) have ports that depend on mpich
(which itself is now a stub and depends on mpich-default) now use
MPICC=${prefix}/bin/mpicc-mp (or whatever is required for the
particular package) and depend on path:bin/mpicc-mp:mpich (might be
satisfied by mpich-devel-default) to insulate packages from the
current 'port select --set mpich mpich-XXX' setting. All of the
flavors use mpich-default's headers (and therefore depend on
mpich-default).

The mpich-default package builds just like (or at least is intended
to) the current mpich (system default CC/CXX; variant requested
fortran (gcc48 by default)) using the "fortran recipe." The other
mpich-COMPILER flavors are intended for users where mpich is the
endpoint of MP support, and the tools created are being used for
"external" work. These wrap the requested CC/CXX in addition to
fortran (depending on variant; using the recipe for non-gccNN ports,
and the matching gfortan for the gccNN ones.)

There is also a set of conflicting mpich-devel packages set up in the same way.

Let me know what you think / if that seems reasonable and I'll make
the changes (in the branch) to ports depending on mpich and then merge
everything at once back into trunk.

​Original message.

(1) users/eborisch/dports/science/mpich (2) users/eborisch/dports/sysutils/mpich_select

[eborisch (Eric A. Borisch)]

Closed 39428 as duplicate. Will use this ticket to track updated (subports instead of variants) mpich / mpich_select progress.

[eborisch (Eric A. Borisch)]

I've got a set of changes ready over here users/eborisch/dports@110423:110971 that splits mpich and mpich-devel up into a set of subparts. A user can either use mpich and family or mpich-devel and family.

For each set, there is a mpich[-devel]-default that installs the headers as well as a set if '-mp' suffixed binaries and lib/mpich[-devel]-mp/ libraries. Any port should depend upon and use bin/mpicc-mp and friends. These will use the MacPorts' default c/c++ compilers, and a gccXX-based fortran using 'fortran recipe' variants.

The other (mpich-clangXX, mpich-llvm, etc) subports wrap the specified compiler (also with the fortran recipe for the non-gccXX flavors, and with a default +fortran for those) and are intended for users that are interested in using mpich for development of MPI tools outside the scope of MacPorts and want a particular compiler for "reasons."

I've CC'd maintainers of ports that depend on mpich. As you'll see in the changeset above I've got changes in place for those ports, but to be honest, I haven't built every single one of them. Please take a look and let me know if you have any concerns before I merge these changes into trunk.

[eborisch (Eric A. Borisch)]

Oh, and there is also an mpich_select that permits users to select which port mpicc/mpicxx/etc. points to. Again, ports should be depending on mpich-default and using bin/mpi(cc|cxx|f70|f90)-mp, so the links should not impact the ports, so long as they can be directed to use the *-mp wrappers, and not search for mpicc explicitly. I've put in tweaks for ports I could identify that didn't have a configure switch / env to set the wrapper names.

[eborisch (Eric A. Borisch)]

Committed in r111260, r111265, r111271, and r111272.