I have now built and executed Hilbert. I have done a couple of builds, one with MPI_DIR set to nothing and one with MPI_DIR set to /opt/local. Both build and seem to work. I had replaced the released version of the file detect.pl with the development version. So, the bottom line seems simple: the culprit was the detect.pl.
Please let me know if you think my conclusions have issues. Otherwise, I suggest that the dev version of detect.pl be back-ported to the existing Hilbert release. Thus no change is needed in the Hilbert version of osx-macports.cfg. Thanks to all you helped me sort out this. Comer On Tue, Jul 7, 2015 at 2:07 PM, Comer Duncan <[email protected]> wrote: > Hi Ian, > > The cfg file I use _is_ the same as the stock osx_macports.cfg. Now > however I have, after Steve's suggestion, replaced "MPI_DIR=/opt/local" > with "MPI_DIR=" (ie nothing) and tried to build with that. If this > assignment needs to be something else, I need for the developers to confirm > that. So, I have already tried the stock optionlist with a crash as the > result. I sent to query about replacing detect.pl with the version which > puts mpiCC last, as that was what I used when I was using the dev version. > I am using Hilbert now, since using the dev version resulted in a problem > due to it being the case that one day a few weeks ago a change in the dev > version resulted in the build crashing. Sticking with Hilbert is what I > will do. So my question was can I go ahead and replace the Hilbert > detect.pl with the dev version of detect.pl. While I think this is likely > ok, I want to proceed carefully. > > I am also looking at the compatibility issue among the various components > mpicc, mpixx, openmpi, and hdf5. I am using the patched flavor of hdf5. A > while back you thought that the patched version of hdf5 was ok to use, so > that is what I am doing (ie the hdf5 is HDF5_DIR = /opt/local). > > The problem I was having was that some updates to macports resulted in > inadvertently inducing inconsistencies/incompatibilities dooming the > builds. Very frustrating. I have not done a macports update in at least two > weeks and have checked the versions of the compiled mpicc, mpixx, openmpi > and hdf5 and so far see no problems....I obviously must be missing > something if compatibility is the problem. And I will not do a macports > update until I can be sure of its effects on the ET builds on my mac > running Yosemite. > > Please have patience. Believe me, I want to get to the use of Eloisa's > CT_Multilevel thorn as soon as possible! > > Comer > > On Tue, Jul 7, 2015 at 1:39 PM, Ian Hinder <[email protected]> wrote: > >> >> On 7 Jul 2015, at 18:55, Comer Duncan <[email protected]> wrote: >> >> HI Steve, >> >> I have reset MPI_DIR= ,i.e. not even a blank and rebuilt, but still >> get the same crash complaints. Am I to set MPI_DIR to something else? >> >> I note that in May I had issues with builds in part due to the mpicc vs >> mpiCC problem on macs. Then in the dev version detect.pl was changed to >> put mpiCC last so the mac would not be as confused. I am using the latest >> release of ET and have looked at the detect.pl file with that. It does >> not have the reordering of the search list for mpicc with mpiCC put last, >> as did the dev version. Somehow I have been assuming that the change to >> detect.pl had been backported to Hilbert, but apparently not?? So, is >> it reasonable to replace the released Hilbert version of detect.pl with >> the dev-fixed version? If that can be done safely I could give that a try. >> >> Thanks for all who help. >> >> >> Hi Comer, >> >> Maybe I missed it, but have you tried using the osx-macports.cfg >> optionlist that we provide? We tested this, and it worked at the time, >> with the list of macports packages. I now see you are using a different >> optionlist. Does the one in simfactory no longer work? Is the issue that >> you are using the release, and a needed fix has not been backported? >> >> >> Comer >> >> On Tue, Jul 7, 2015 at 9:08 AM, Steven R. Brandt <[email protected]> >> wrote: >> >>> Comer, thank you for sending the optionlist. I see that you have >>> >>> MPI_DIR = /opt/local >>> >>> The expectation is that the system can find the mpi c++ compiler wrapper >>> in $(MPI_DIR)/bin. Is that the case? The mpi c++ compiler wrapper may >>> have >>> any of the following names: mpic++, mpiCC, mpicxx, or mpicxx-openmpi-mp. >>> >>> If the mpi c++ wrapper is in your path, then you could simply try >>> unsetting >>> the MPI_DIR variable and building. >>> >>> Cheers, >>> Steve >>> >>> >>> On 07/06/2015 05:33 PM, Frank Loeffler wrote: >>> >>> On Mon, Jul 06, 2015 at 03:30:13PM -0400, Comer Duncan wrote: >>> >>> I have tried building ET for the current released version. I am on a >>> macbook pro running Yosemite. The build script is: >>> >>> On first glance, this looks like a problem with a missing c++ mpi >>> interface (again?). It would be interesting to see your option list and >>> a verbose link line. >>> >>> Frank >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing >>> [email protected]http://lists.einsteintoolkit.org/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.einsteintoolkit.org/mailman/listinfo/users >>> >>> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.einsteintoolkit.org/mailman/listinfo/users >> >> >> -- >> Ian Hinder >> http://members.aei.mpg.de/ianhin >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
