[Users] build error at end

Tue Jul 7 16:04:56 CDT 2015

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 <comer.duncan at gmail.com> 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 <ian.hinder at aei.mpg.de> wrote:
>
>>
>> On 7 Jul 2015, at 18:55, Comer Duncan <comer.duncan at gmail.com> 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 <sbrandt at cct.lsu.edu>
>> 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 listUsers at einsteintoolkit.orghttp://lists.einsteintoolkit.org/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at einsteintoolkit.org
>>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>>
>>>
>> _______________________________________________
>> Users mailing list
>> Users at einsteintoolkit.org
>> http://lists.einsteintoolkit.org/mailman/listinfo/users
>>
>>
>> --
>> Ian Hinder
>> http://members.aei.mpg.de/ianhin
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150707/dd108e2a/attachment-0001.html 