[MacPorts] #40375: new mpich +gcc47 uses clang
#40375: new mpich +gcc47 uses clang -----------------------------+-------------------------------- Reporter: beany_kelly@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Keywords: mpich clang gcc | Port: mpich -----------------------------+-------------------------------- 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. -- Ticket URL: <https://trac.macports.org/ticket/40375> MacPorts <http://www.macports.org/> Ports system for OS X
#40375: new mpich +gcc47 uses clang ----------------------------+------------------------ Reporter: beany_kelly@… | Owner: eborisch@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mpich | ----------------------------+------------------------ Changes (by ryandesign@…): * cc: eborisch (removed) * cc: jeremyhu@… (added) * owner: macports-tickets@… => eborisch@… * keywords: mpich clang gcc => -- Ticket URL: <https://trac.macports.org/ticket/40375#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#40375: new mpich +gcc47 uses clang ----------------------------+------------------------ Reporter: beany_kelly@… | Owner: eborisch@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mpich | ----------------------------+------------------------ Comment (by jeremyhu@…): Discussion on macports-dev recently points to this becoming multiple subports. For example, mpich-gcc47 will be built by clang and use gcc47. -- Ticket URL: <https://trac.macports.org/ticket/40375#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#40375: new mpich +gcc47 uses clang ----------------------------+------------------------ Reporter: beany_kelly@… | Owner: eborisch@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mpich | ----------------------------+------------------------ Comment (by beany_kelly@…): Replying to [comment:2 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? -- Ticket URL: <https://trac.macports.org/ticket/40375#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#40375: new mpich +gcc47 uses clang ----------------------------+------------------------ Reporter: beany_kelly@… | Owner: eborisch@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mpich | ----------------------------+------------------------ Comment (by jeremyhu@…): Replying to [comment:3 beany_kelly@…]:
Replying to [comment:2 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. -- Ticket URL: <https://trac.macports.org/ticket/40375#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#40375: new mpich +gcc47 uses clang ----------------------------+------------------------ Reporter: beany_kelly@… | Owner: eborisch@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mpich | ----------------------------+------------------------ Comment (by 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). -- Ticket URL: <https://trac.macports.org/ticket/40375#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X
#40375: new mpich +gcc47 uses clang ----------------------------+------------------------ Reporter: beany_kelly@… | Owner: eborisch@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mpich | ----------------------------+------------------------ Comment (by eborisch@…): 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. }}} [https://lists.macosforge.org/pipermail/macports- dev/2013-August/024170.html Original message.] (1) [source:users/eborisch/dports/science/mpich] (2) [source:users/eborisch/dports/sysutils/mpich_select] -- Ticket URL: <https://trac.macports.org/ticket/40375#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
#40375: new mpich +gcc47 uses clang ----------------------------+------------------------ Reporter: beany_kelly@… | Owner: eborisch@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mpich | ----------------------------+------------------------ Comment (by eborisch@…): Closed [ticket:39428] as duplicate. Will use this ticket to track updated (subports instead of variants) mpich / mpich_select progress. -- Ticket URL: <https://trac.macports.org/ticket/40375#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#40375: new mpich +gcc47 uses clang ----------------------------+------------------------ Reporter: beany_kelly@… | Owner: eborisch@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mpich | ----------------------------+------------------------ Changes (by eborisch@…): * cc: dweber@…, hum@…, mmoll@…, ram@…, takeshi@… (added) Comment: I've got a set of changes ready over here [diff: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. -- Ticket URL: <https://trac.macports.org/ticket/40375#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#40375: new mpich +gcc47 uses clang ----------------------------+------------------------ Reporter: beany_kelly@… | Owner: eborisch@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: mpich | ----------------------------+------------------------ Comment (by eborisch@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/40375#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X
#40375: new mpich +gcc47 uses clang ----------------------------+------------------------ Reporter: beany_kelly@… | Owner: eborisch@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: fixed | Keywords: Port: mpich | ----------------------------+------------------------ Changes (by eborisch@…): * status: new => closed * resolution: => fixed Comment: Committed in r111260, r111265, r111271, and r111272. -- Ticket URL: <https://trac.macports.org/ticket/40375#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts