Ok, I deactivated mpich and have run simfactory/bin/sim build --optionlist=osx-macports.cfg >build2.log 2>&1 and get similar errors. I have pasted the contents of build2.log to http://pastebin.com/kcua0vKQ. It does not seem that the deactivation of mpich had the desired effect.
Thanks.
Comer
On Wed, May 20, 2015 at 12:24 PM, Comer Duncan comer.duncan@gmail.com wrote:
Erik,
Thanks. I think I had mpich first and then added openmpi. I will deactivate mpich-default. The question is do I need to run simfactory/bin/sim build --optionlist=osx-macports.cfg >build.log 2>&1 with build2.log instead of build.log so I get a new log file? Will it do just what is necessary relative to openmpi libs or do the whole business from scratch?
Comer
On Wed, May 20, 2015 at 12:13 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
I would have only one MPI implementation active. I assume you had mpich active, and then added openmpi when you followed our instructions. You can try to deactivate mpich: "sudo port deactivate mpich-default". Alternatively, you can deactivate openmpi. After this, you would need to configure and build from scratch.
-erik
On Wed, May 20, 2015 at 12:04 PM, Comer Duncan comer.duncan@gmail.com wrote:
Hi Erik,
Here is what I find:
ComerMacProRetina:Cactus comerduncan$ /opt/local/bin/mpiCC -showme /usr/bin/clang -I/opt/local/include/openmpi-mp -Wl,-flat_namespace -L/opt/local/lib/openmpi-mp -lmpi ComerMacProRetina:Cactus comerduncan$ port installed | grep mpi mpi-doc @3.1.3_0 mpi-doc @3.1.4_0 (active) mpi_select @0.0_3 (active) mpich-default @3.1.3_0+gcc49 mpich-default @3.1.4_0+gcc49 (active) openmpi @1.7.5_3 (active) openmpi-default @1.7.5_3+gcc47 (active) petsc @3.5.3_1+accelerate+hwloc+mpich petsc @3.5.3_1+accelerate+hwloc+openmpi (active)
Any recommendations for changes?
Thanks.
Comer
On Wed, May 20, 2015 at 9:26 AM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
Maybe you have two different MPI implementations installed. What is the output of "/opt/local/bin/mpiCC -showme"? What is the output of "port installed | grep mpi"?
-erik
On Wed, May 20, 2015 at 9:20 AM, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
I did make sure that all ports mentioned in the osx-macports.cfg file were done before attempting a build. I've followed your suggestion on rebuilding and have pasted the build log to http://pastebin.com/ka7c3QT5
Thanks for your help.
Comer
On Tue, May 19, 2015 at 6:27 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 19 May 2015, at 21:03, Comer Duncan comer.duncan@gmail.com wrote:
I have tried to build the new release on my local macbook. I am running Yosemite and am using the optionlist for macports. Here is the part of the make which chokes: . . . Undefined symbols for architecture x86_64: "MPI::Win::Free()", referenced from: vtable for MPI::Win in libthorn_PeriodicCarpet.a(periodic.cc.o) vtable for MPI::Win in libthorn_Carpet.a(helpers.cc.o) vtable for MPI::Win in libthorn_CarpetEvolutionMask.a(evolution_mask.cc.o) vtable for MPI::Win in libthorn_CarpetIOASCII.a(ioascii.cc.o) vtable for MPI::Win in libthorn_CarpetIOBasic.a(iobasic.cc.o) vtable for MPI::Win in libthorn_CarpetIOHDF5.a(Input.cc.o) vtable for MPI::Win in libthorn_CarpetIOHDF5.a(CarpetIOHDF5.cc.o) ... "MPI::Comm::Comm()", referenced from: MPI::Intercomm::Merge(bool) const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Intracomm::Split(int, int) const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Intracomm::Create(MPI::Group const&) const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Graphcomm::Clone() const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Cartcomm::Clone() const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Intracomm::Clone() const in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Intracomm::Create_graph(int, int const*, int const*, bool) const in libthorn_PeriodicCarpet.a(periodic.cc.o) ... "MPI::Datatype::Free()", referenced from: vtable for MPI::Datatype in libthorn_PeriodicCarpet.a(periodic.cc.o) vtable for MPI::Datatype in libthorn_Carpet.a(helpers.cc.o) vtable for MPI::Datatype in libthorn_CarpetEvolutionMask.a(evolution_mask.cc.o) vtable for MPI::Datatype in libthorn_CarpetIOASCII.a(ioascii.cc.o) vtable for MPI::Datatype in libthorn_CarpetIOBasic.a(iobasic.cc.o) vtable for MPI::Datatype in libthorn_CarpetIOHDF5.a(Input.cc.o) vtable for MPI::Datatype in libthorn_CarpetIOHDF5.a(CarpetIOHDF5.cc.o) ... "_ompi_mpi_cxx_op_intercept", referenced from: MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_PeriodicCarpet.a(periodic.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_Carpet.a(helpers.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_CarpetEvolutionMask.a(evolution_mask.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_CarpetIOASCII.a(ioascii.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_CarpetIOBasic.a(iobasic.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_CarpetIOHDF5.a(Input.cc.o) MPI::Op::Init(void (*)(void const*, void*, int, MPI::Datatype const&), bool) in libthorn_CarpetIOHDF5.a(CarpetIOHDF5.cc.o) ... ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status make[1]: *** [/Users/comerduncan/Cactus/exe/cactus_sim] Error 1 make: *** [sim] Error 2
Here is the build I did:
simfactory/bin/sim build --optionlist=/Users/comerduncan/Cactus/simfactory/mdb/optionlists/osx-macports.cfg
Can you please help me figure out what went wrong?
Hi Comer,
My guess would be that there might be more than one version of MPI installed, or something in the MPI configuration script didn't work quite right. Did you install all the ports recommended in the comment in the os-macports.cfg optionlist? Can you post the output from the full build? I suggest to remove the configuration
rm -rf configs/sim
and then build, keeping all output:
simfactory/bin/sim build --optionlist=osx-macports.cfg >build.log 2>&1
You could then copy and paste build.log into http://pastebin.com and include the link in your reply (to avoid having a large attachment on the mailing list).
-- Ian Hinder http://members.aei.mpg.de/ianhin
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
On 20 May 2015, at 18:35, Comer Duncan comer.duncan@gmail.com wrote:
Ok, I deactivated mpich and have run simfactory/bin/sim build --optionlist=osx-macports.cfg >build2.log 2>&1 and get similar errors. I have pasted the contents of build2.log to http://pastebin.com/kcua0vKQ. It does not seem that the deactivation of mpich had the desired effect.
You probably need to do a clean build by removing configs/sim and building again (this is usually good advice in general, if you suspect there is something weird happening with the build system). Having both MPI versions' header files around during compilation might have caused the problems.
Hi Ian,
Oh well. You can find the contents of build3.log on http://pastebin.com/0q9NNAT4 and I note nothing different, or so it seems. Here is a query about mpich and openmpi on my system:
ComerMacProRetina:Cactus comerduncan$ port installed | grep mpich mpich-default @3.1.3_0+gcc49 mpich-default @3.1.4_0+gcc49 petsc @3.5.3_1+accelerate+hwloc+mpich ComerMacProRetina:Cactus comerduncan$ port installed | grep openmpi openmpi @1.7.5_3 (active) openmpi-default @1.7.5_3+gcc47 (active) petsc @3.5.3_1+accelerate+hwloc+openmpi (active)
Also, I note in the osx-macport config file that the compiler specified is gcc49 to wit:
CPP = cpp-mp-4.9 FPP = cpp-mp-4.9 CC = gcc-mp-4.9 CXX = g++-mp-4.9 F90 = gfortran-mp-4.9
However, note that the active openmpi-default points to gcc47. Could this be a problem?
Thanks for your help.
Comer
On Wed, May 20, 2015 at 12:55 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 20 May 2015, at 18:35, Comer Duncan comer.duncan@gmail.com wrote:
Ok, I deactivated mpich and have run simfactory/bin/sim build --optionlist=osx-macports.cfg >build2.log 2>&1 and get similar errors. I have pasted the contents of build2.log to http://pastebin.com/kcua0vKQ. It does not seem that the deactivation of mpich had the desired effect.
You probably need to do a clean build by removing configs/sim and building again (this is usually good advice in general, if you suspect there is something weird happening with the build system). Having both MPI versions' header files around during compilation might have caused the problems.
-- Ian Hinder http://members.aei.mpg.de/ianhin
On Wed, May 20, 2015 at 02:26:15PM -0400, Comer Duncan wrote:
Oh well. You can find the contents of build3.log on http://pastebin.com/0q9NNAT4 and I note nothing different, or so it seems.
From your log I see that Cactus says: Found MPI compiler wrapper at /opt/local/bin/mpiCC. This is likely the problem. Apple still doesn't use a case sensitive filesystem by default, which means this is the same as mpicc, which is the C compiler. The compiler itself is smart enough (in the case of gnu) to figure this out at compile time, so you don't get an error there. At link time however, (and because Cactus uses the C++ compiler for linking), this can result in C++ libraries not being linked, and thus C++ symbols are missing (as seems to be the case in your log).
Now, the thorn MPI should have picked up /opt/local/bin/mpic++ before mpiCC, if the former exists. Does it? If not - is there some package you still need to install (like openmpi-c++ or such)?
Frank
So close. The command is called "mpicxx", not "mpic++". And we don't look for this spelling.
-erik
On Wed, May 20, 2015 at 2:56 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Wed, May 20, 2015 at 02:26:15PM -0400, Comer Duncan wrote:
Oh well. You can find the contents of build3.log on http://pastebin.com/0q9NNAT4 and I note nothing different, or so it
seems.
From your log I see that Cactus says: Found MPI compiler wrapper at /opt/local/bin/mpiCC. This is likely the problem. Apple still doesn't use a case sensitive filesystem by default, which means this is the same as mpicc, which is the C compiler. The compiler itself is smart enough (in the case of gnu) to figure this out at compile time, so you don't get an error there. At link time however, (and because Cactus uses the C++ compiler for linking), this can result in C++ libraries not being linked, and thus C++ symbols are missing (as seems to be the case in your log).
Now, the thorn MPI should have picked up /opt/local/bin/mpic++ before mpiCC, if the former exists. Does it? If not - is there some package you still need to install (like openmpi-c++ or such)?
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
It looks to me like we do look for mpicxx... after we look for mpiCC.
Cheers, Steve
On 05/20/2015 03:12 PM, Erik Schnetter wrote:
So close. The command is called "mpicxx", not "mpic++". And we don't look for this spelling.
-erik
On Wed, May 20, 2015 at 2:56 PM, Frank Loeffler <knarf@cct.lsu.edu mailto:knarf@cct.lsu.edu> wrote:
On Wed, May 20, 2015 at 02:26:15PM -0400, Comer Duncan wrote: > Oh well. You can find the contents of build3.log on > http://pastebin.com/0q9NNAT4 and I note nothing different, or so it seems. From your log I see that Cactus says: Found MPI compiler wrapper at /opt/local/bin/mpiCC. This is likely the problem. Apple still doesn't use a case sensitive filesystem by default, which means this is the same as mpicc, which is the C compiler. The compiler itself is smart enough (in the case of gnu) to figure this out at compile time, so you don't get an error there. At link time however, (and because Cactus uses the C++ compiler for linking), this can result in C++ libraries not being linked, and thus C++ symbols are missing (as seems to be the case in your log). Now, the thorn MPI should have picked up /opt/local/bin/mpic++ before mpiCC, if the former exists. Does it? If not - is there some package you still need to install (like openmpi-c++ or such)? Frank _______________________________________________ Users mailing list Users@einsteintoolkit.org <mailto:Users@einsteintoolkit.org> http://lists.einsteintoolkit.org/mailman/listinfo/users-- Erik Schnetter <schnetter@cct.lsu.edu mailto:schnetter@cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Steve
Yes, we did. I now changed the order.
-erik
On Thu, May 21, 2015 at 10:40 AM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
It looks to me like we do look for mpicxx... after we look for mpiCC.
Cheers, Steve
On 05/20/2015 03:12 PM, Erik Schnetter wrote:
So close. The command is called "mpicxx", not "mpic++". And we don't look for this spelling.
-erik
On Wed, May 20, 2015 at 2:56 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Wed, May 20, 2015 at 02:26:15PM -0400, Comer Duncan wrote:
Oh well. You can find the contents of build3.log on http://pastebin.com/0q9NNAT4 and I note nothing different, or so it
seems.
From your log I see that Cactus says: Found MPI compiler wrapper at /opt/local/bin/mpiCC. This is likely the problem. Apple still doesn't use a case sensitive filesystem by default, which means this is the same as mpicc, which is the C compiler. The compiler itself is smart enough (in the case of gnu) to figure this out at compile time, so you don't get an error there. At link time however, (and because Cactus uses the C++ compiler for linking), this can result in C++ libraries not being linked, and thus C++ symbols are missing (as seems to be the case in your log).
Now, the thorn MPI should have picked up /opt/local/bin/mpic++ before mpiCC, if the former exists. Does it? If not - is there some package you still need to install (like openmpi-c++ or such)?
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing listUsers@einsteintoolkit.orghttp://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Erik,
Should I go ahead and do a from scratch download including GetComponents?
Comer
On Thu, May 21, 2015 at 10:50 AM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Steve
Yes, we did. I now changed the order.
-erik
On Thu, May 21, 2015 at 10:40 AM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
It looks to me like we do look for mpicxx... after we look for mpiCC.
Cheers, Steve
On 05/20/2015 03:12 PM, Erik Schnetter wrote:
So close. The command is called "mpicxx", not "mpic++". And we don't look for this spelling.
-erik
On Wed, May 20, 2015 at 2:56 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Wed, May 20, 2015 at 02:26:15PM -0400, Comer Duncan wrote:
Oh well. You can find the contents of build3.log on http://pastebin.com/0q9NNAT4 and I note nothing different, or so it
seems.
From your log I see that Cactus says: Found MPI compiler wrapper at /opt/local/bin/mpiCC. This is likely the problem. Apple still doesn't use a case sensitive filesystem by default, which means this is the same as mpicc, which is the C compiler. The compiler itself is smart enough (in the case of gnu) to figure this out at compile time, so you don't get an error there. At link time however, (and because Cactus uses the C++ compiler for linking), this can result in C++ libraries not being linked, and thus C++ symbols are missing (as seems to be the case in your log).
Now, the thorn MPI should have picked up /opt/local/bin/mpic++ before mpiCC, if the former exists. Does it? If not - is there some package you still need to install (like openmpi-c++ or such)?
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing listUsers@einsteintoolkit.orghttp://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Comer
No, not yet -- the change is currently only in the development version, not yet in the release.
-erik
On Thu, May 21, 2015 at 11:25 AM, Comer Duncan comer.duncan@gmail.com wrote:
Erik,
Should I go ahead and do a from scratch download including GetComponents?
Comer
On Thu, May 21, 2015 at 10:50 AM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Steve
Yes, we did. I now changed the order.
-erik
On Thu, May 21, 2015 at 10:40 AM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
It looks to me like we do look for mpicxx... after we look for mpiCC.
Cheers, Steve
On 05/20/2015 03:12 PM, Erik Schnetter wrote:
So close. The command is called "mpicxx", not "mpic++". And we don't look for this spelling.
-erik
On Wed, May 20, 2015 at 2:56 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Wed, May 20, 2015 at 02:26:15PM -0400, Comer Duncan wrote:
Oh well. You can find the contents of build3.log on http://pastebin.com/0q9NNAT4 and I note nothing different, or so it
seems.
From your log I see that Cactus says: Found MPI compiler wrapper at /opt/local/bin/mpiCC. This is likely the problem. Apple still doesn't use a case sensitive filesystem by default, which means this is the same as mpicc, which is the C compiler. The compiler itself is smart enough (in the case of gnu) to figure this out at compile time, so you don't get an error there. At link time however, (and because Cactus uses the C++ compiler for linking), this can result in C++ libraries not being linked, and thus C++ symbols are missing (as seems to be the case in your log).
Now, the thorn MPI should have picked up /opt/local/bin/mpic++ before mpiCC, if the former exists. Does it? If not - is there some package you still need to install (like openmpi-c++ or such)?
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing listUsers@einsteintoolkit.orghttp://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Thu, May 21, 2015 at 11:25:47AM -0400, Comer Duncan wrote:
Should I go ahead and do a from scratch download including GetComponents?
You don't need to re-download everyone. Building from scratch would be best though. Before that, if you use the development version, do an 'svn update' in arrangements/ExternalLibraries/MPI. If you use the release, replace the file arrangements/ExternalLibraries/MPI/src/detect.pl by this one https://svn.cactuscode.org/projects/ExternalLibraries/MPI/trunk/src/detect.p...
Frank
Hi Frank,
Thanks for the tips. I have replaced the detect.pl file and am rebuilding after rm -f configs/sim.
Comer
On Thu, May 21, 2015 at 11:30 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, May 21, 2015 at 11:25:47AM -0400, Comer Duncan wrote:
Should I go ahead and do a from scratch download including GetComponents?
You don't need to re-download everyone. Building from scratch would be best though. Before that, if you use the development version, do an 'svn update' in arrangements/ExternalLibraries/MPI. If you use the release, replace the file arrangements/ExternalLibraries/MPI/src/detect.pl by this one
https://svn.cactuscode.org/projects/ExternalLibraries/MPI/trunk/src/detect.p...
Frank
I have rebuilt Hilbert using the new detect.pl file suggested and get a make crash but this time referring to seemingly different compile problems. I have pasted the build4.log file to http://pastebin.com/kECKTkqr
Thanks for the community help!
Comer
On Thu, May 21, 2015 at 11:52 AM, Comer Duncan comer.duncan@gmail.com wrote:
Hi Frank,
Thanks for the tips. I have replaced the detect.pl file and am rebuilding after rm -f configs/sim.
Comer
On Thu, May 21, 2015 at 11:30 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, May 21, 2015 at 11:25:47AM -0400, Comer Duncan wrote:
Should I go ahead and do a from scratch download including
GetComponents?
You don't need to re-download everyone. Building from scratch would be best though. Before that, if you use the development version, do an 'svn update' in arrangements/ExternalLibraries/MPI. If you use the release, replace the file arrangements/ExternalLibraries/MPI/src/detect.pl by this one
https://svn.cactuscode.org/projects/ExternalLibraries/MPI/trunk/src/detect.p...
Frank
On Thu, May 21, 2015 at 01:52:25PM -0400, Comer Duncan wrote:
I have rebuilt Hilbert using the new detect.pl file suggested and get a make crash but this time referring to seemingly different compile problems. I have pasted the build4.log file to http://pastebin.com/kECKTkqr
Which Mac OS version do you have again? Could it be connected to this?
http://stackoverflow.com/questions/15963277/performance-api-on-mac-10-8
(there is no solution given there, but the symptoms fit)
Frank
HI Frank,
I am running 10.10.3 (14D136) on a macbook pro with the following properties:
Version 10.10.3 (14D136) MacBook Pro (Retina, 15-inch, Mid 2014) Processor 2.5 Ghz Intel Core i7 (4 cores) 16 GB with 1TB SSD
I am up to date with macports (I do this every week or so).
I noticed complaints about papi but since builds don't crash with such complaints I forged ahead. I also note in the build logs multiple mentions (1405!) of Nonexistent include directories. How come such warnings are there in a new release? Maybe unrelated or not worth worrying about?
Please help.
Thanks.
Comer
On Thu, May 21, 2015 at 2:30 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, May 21, 2015 at 01:52:25PM -0400, Comer Duncan wrote:
I have rebuilt Hilbert using the new detect.pl file suggested and get a make crash but this time referring to seemingly different compile
problems.
I have pasted the build4.log file to http://pastebin.com/kECKTkqr
Which Mac OS version do you have again? Could it be connected to this?
http://stackoverflow.com/questions/15963277/performance-api-on-mac-10-8
(there is no solution given there, but the symptoms fit)
Frank
Comer
I agree with you that the PAPI errors seem harmless.
The problem seems to be that something is wrong with vectorization. The error is reported inside a compiler-provided file. I don't know why these errors would now suddenly appear, as they were not there before. It looks as if something related to the C++ compiler changed.
This is quite annoying, since several of us tested this option list, and it worked for all of us...
Can you send us the output of
g++-mp-4.9 --version
and
/opt/local/bin/mpicxx --version
?
-erik
On Thu, May 21, 2015 at 2:44 PM, Comer Duncan comer.duncan@gmail.com wrote:
HI Frank,
I am running 10.10.3 (14D136) on a macbook pro with the following properties:
Version 10.10.3 (14D136) MacBook Pro (Retina, 15-inch, Mid 2014) Processor 2.5 Ghz Intel Core i7 (4 cores) 16 GB with 1TB SSD
I am up to date with macports (I do this every week or so).
I noticed complaints about papi but since builds don't crash with such complaints I forged ahead. I also note in the build logs multiple mentions (1405!) of Nonexistent include directories. How come such warnings are there in a new release? Maybe unrelated or not worth worrying about?
Please help.
Thanks.
Comer
On Thu, May 21, 2015 at 2:30 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, May 21, 2015 at 01:52:25PM -0400, Comer Duncan wrote:
I have rebuilt Hilbert using the new detect.pl file suggested and get a make crash but this time referring to seemingly different compile
problems.
I have pasted the build4.log file to http://pastebin.com/kECKTkqr
Which Mac OS version do you have again? Could it be connected to this?
http://stackoverflow.com/questions/15963277/performance-api-on-mac-10-8
(there is no solution given there, but the symptoms fit)
Frank
Erik,
Sure. Here you go.
ComerMacProRetina:Cactus comerduncan$ g++-mp-4.9 --version g++-mp-4.9 (MacPorts gcc49 4.9.2_1) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and
ComerMacProRetina:Cactus comerduncan$ /opt/local/bin/mpicxx --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix
I just did my usual macports maintenance script yesterday:
ComerMacProRetina:bin comerduncan$ cat portupdateupgrade echo '------------selfupdate------------------' sudo port selfupdate echo '------------outdated ports--------------' sudo port outdated echo '------------upgrade outdated ports------' sudo port upgrade outdated
Has macports stuff been polluted? I note that on May 20 the software update for mac osx included installed updates of Xcode to version 6.3.2 and Command Line Tools version 6.3. I am wondering whether the attempts at building Cactus intersected macports updates performed with updated Xcode/Command LIne Tools, so that the macport collection might be in somewhat of a conflicted state?
Comer
On Thu, May 21, 2015 at 3:16 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
I agree with you that the PAPI errors seem harmless.
The problem seems to be that something is wrong with vectorization. The error is reported inside a compiler-provided file. I don't know why these errors would now suddenly appear, as they were not there before. It looks as if something related to the C++ compiler changed.
This is quite annoying, since several of us tested this option list, and it worked for all of us...
Can you send us the output of
g++-mp-4.9 --version
and
/opt/local/bin/mpicxx --version
?
-erik
On Thu, May 21, 2015 at 2:44 PM, Comer Duncan comer.duncan@gmail.com wrote:
HI Frank,
I am running 10.10.3 (14D136) on a macbook pro with the following properties:
Version 10.10.3 (14D136) MacBook Pro (Retina, 15-inch, Mid 2014) Processor 2.5 Ghz Intel Core i7 (4 cores) 16 GB with 1TB SSD
I am up to date with macports (I do this every week or so).
I noticed complaints about papi but since builds don't crash with such complaints I forged ahead. I also note in the build logs multiple mentions (1405!) of Nonexistent include directories. How come such warnings are there in a new release? Maybe unrelated or not worth worrying about?
Please help.
Thanks.
Comer
On Thu, May 21, 2015 at 2:30 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, May 21, 2015 at 01:52:25PM -0400, Comer Duncan wrote:
I have rebuilt Hilbert using the new detect.pl file suggested and get
a
make crash but this time referring to seemingly different compile
problems.
I have pasted the build4.log file to http://pastebin.com/kECKTkqr
Which Mac OS version do you have again? Could it be connected to this?
http://stackoverflow.com/questions/15963277/performance-api-on-mac-10-8
(there is no solution given there, but the symptoms fit)
Frank
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Comer
Thanks. It seems that MPI was built against a different C++ library. I now think that the package "openmpi-default" is wrong; there should be "openmpi-gcc49" instead. If so, then this is an error in the instructions we list in the osx-macports.cfg file. Can you uninstall openmpi-default, and install openmpi-gcc49 instead?
-erik
On Thu, May 21, 2015 at 3:28 PM, Comer Duncan comer.duncan@gmail.com wrote:
Erik,
Sure. Here you go.
ComerMacProRetina:Cactus comerduncan$ g++-mp-4.9 --version g++-mp-4.9 (MacPorts gcc49 4.9.2_1) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and
ComerMacProRetina:Cactus comerduncan$ /opt/local/bin/mpicxx --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix
I just did my usual macports maintenance script yesterday:
ComerMacProRetina:bin comerduncan$ cat portupdateupgrade echo '------------selfupdate------------------' sudo port selfupdate echo '------------outdated ports--------------' sudo port outdated echo '------------upgrade outdated ports------' sudo port upgrade outdated
Has macports stuff been polluted? I note that on May 20 the software update for mac osx included installed updates of Xcode to version 6.3.2 and Command Line Tools version 6.3. I am wondering whether the attempts at building Cactus intersected macports updates performed with updated Xcode/Command LIne Tools, so that the macport collection might be in somewhat of a conflicted state?
Comer
On Thu, May 21, 2015 at 3:16 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
I agree with you that the PAPI errors seem harmless.
The problem seems to be that something is wrong with vectorization. The error is reported inside a compiler-provided file. I don't know why these errors would now suddenly appear, as they were not there before. It looks as if something related to the C++ compiler changed.
This is quite annoying, since several of us tested this option list, and it worked for all of us...
Can you send us the output of
g++-mp-4.9 --version
and
/opt/local/bin/mpicxx --version
?
-erik
On Thu, May 21, 2015 at 2:44 PM, Comer Duncan comer.duncan@gmail.com wrote:
HI Frank,
I am running 10.10.3 (14D136) on a macbook pro with the following properties:
Version 10.10.3 (14D136) MacBook Pro (Retina, 15-inch, Mid 2014) Processor 2.5 Ghz Intel Core i7 (4 cores) 16 GB with 1TB SSD
I am up to date with macports (I do this every week or so).
I noticed complaints about papi but since builds don't crash with such complaints I forged ahead. I also note in the build logs multiple mentions (1405!) of Nonexistent include directories. How come such warnings are there in a new release? Maybe unrelated or not worth worrying about?
Please help.
Thanks.
Comer
On Thu, May 21, 2015 at 2:30 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, May 21, 2015 at 01:52:25PM -0400, Comer Duncan wrote:
I have rebuilt Hilbert using the new detect.pl file suggested and
get a
make crash but this time referring to seemingly different compile
problems.
I have pasted the build4.log file to http://pastebin.com/kECKTkqr
Which Mac OS version do you have again? Could it be connected to this?
http://stackoverflow.com/questions/15963277/performance-api-on-mac-10-8
(there is no solution given there, but the symptoms fit)
Frank
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Erik,
Ok, here goes. First,
ComerMacProRetina:~ comerduncan$ sudo port uninstall openmpi-default Password: ---> Unable to uninstall openmpi-default @1.7.5_3+gcc47, the following ports depend on it: ---> openmpi @1.7.5_3 ---> petsc @3.5.3_1+accelerate+hwloc+openmpi ---> petsc @3.5.3_2+accelerate+hwloc+openmpi Error: org.macports.uninstall for port openmpi-default returned: Please uninstall the ports that depend on openmpi-default first. Please see the log file for port openmpi-default for details:
/opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_openmpi-default-1.7.5_3_a272d6c16ef1296938f908cc0944080d49c66489dfb63de25e65dcab22608f20-12289/openmpi-default/main.log Warning: Failed to execute portfile from registry for openmpi-default @1.7.5_3+gcc47 ---> Unable to uninstall openmpi-default @1.7.5_3+gcc47, the following ports depend on it: ---> openmpi @1.7.5_3 ---> petsc @3.5.3_1+accelerate+hwloc+openmpi ---> petsc @3.5.3_2+accelerate+hwloc+openmpi Error: port uninstall failed: Please uninstall the ports that depend on openmpi-default first.
So I uninstalled the three ports which depend on openmpi-default with success. Then I
ComerMacProRetina:~ comerduncan$ sudo port uninstall openmpi-default ---> Deactivating openmpi-default @1.7.5_3+gcc47 ---> Cleaning openmpi-default ---> Uninstalling openmpi-default @1.7.5_3+gcc47 ---> Cleaning openmpi-default
Then I installed openmpi-gcc49 as suggested and checked it:
ComerMacProRetina:~ comerduncan$ port installed | grep openmpi openmpi-gcc49 @1.7.5_3+fortran (active)
Is this what you had in mind? Assuming it is, I am going to try another build and will report back what happens.
Comer
On Thu, May 21, 2015 at 3:46 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
Thanks. It seems that MPI was built against a different C++ library. I now think that the package "openmpi-default" is wrong; there should be "openmpi-gcc49" instead. If so, then this is an error in the instructions we list in the osx-macports.cfg file. Can you uninstall openmpi-default, and install openmpi-gcc49 instead?
-erik
On Thu, May 21, 2015 at 3:28 PM, Comer Duncan comer.duncan@gmail.com wrote:
Erik,
Sure. Here you go.
ComerMacProRetina:Cactus comerduncan$ g++-mp-4.9 --version g++-mp-4.9 (MacPorts gcc49 4.9.2_1) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and
ComerMacProRetina:Cactus comerduncan$ /opt/local/bin/mpicxx --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix
I just did my usual macports maintenance script yesterday:
ComerMacProRetina:bin comerduncan$ cat portupdateupgrade echo '------------selfupdate------------------' sudo port selfupdate echo '------------outdated ports--------------' sudo port outdated echo '------------upgrade outdated ports------' sudo port upgrade outdated
Has macports stuff been polluted? I note that on May 20 the software update for mac osx included installed updates of Xcode to version 6.3.2 and Command Line Tools version 6.3. I am wondering whether the attempts at building Cactus intersected macports updates performed with updated Xcode/Command LIne Tools, so that the macport collection might be in somewhat of a conflicted state?
Comer
On Thu, May 21, 2015 at 3:16 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
I agree with you that the PAPI errors seem harmless.
The problem seems to be that something is wrong with vectorization. The error is reported inside a compiler-provided file. I don't know why these errors would now suddenly appear, as they were not there before. It looks as if something related to the C++ compiler changed.
This is quite annoying, since several of us tested this option list, and it worked for all of us...
Can you send us the output of
g++-mp-4.9 --version
and
/opt/local/bin/mpicxx --version
?
-erik
On Thu, May 21, 2015 at 2:44 PM, Comer Duncan comer.duncan@gmail.com wrote:
HI Frank,
I am running 10.10.3 (14D136) on a macbook pro with the following properties:
Version 10.10.3 (14D136) MacBook Pro (Retina, 15-inch, Mid 2014) Processor 2.5 Ghz Intel Core i7 (4 cores) 16 GB with 1TB SSD
I am up to date with macports (I do this every week or so).
I noticed complaints about papi but since builds don't crash with such complaints I forged ahead. I also note in the build logs multiple mentions (1405!) of Nonexistent include directories. How come such warnings are there in a new release? Maybe unrelated or not worth worrying about?
Please help.
Thanks.
Comer
On Thu, May 21, 2015 at 2:30 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, May 21, 2015 at 01:52:25PM -0400, Comer Duncan wrote:
I have rebuilt Hilbert using the new detect.pl file suggested and
get a
make crash but this time referring to seemingly different compile
problems.
I have pasted the build4.log file to http://pastebin.com/kECKTkqr
Which Mac OS version do you have again? Could it be connected to this?
http://stackoverflow.com/questions/15963277/performance-api-on-mac-10-8
(there is no solution given there, but the symptoms fit)
Frank
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Comer
Yes, this looks good.
-erik
On Thu, May 21, 2015 at 4:11 PM, Comer Duncan comer.duncan@gmail.com wrote:
Erik,
Ok, here goes. First,
ComerMacProRetina:~ comerduncan$ sudo port uninstall openmpi-default Password: ---> Unable to uninstall openmpi-default @1.7.5_3+gcc47, the following ports depend on it: ---> openmpi @1.7.5_3 ---> petsc @3.5.3_1+accelerate+hwloc+openmpi ---> petsc @3.5.3_2+accelerate+hwloc+openmpi Error: org.macports.uninstall for port openmpi-default returned: Please uninstall the ports that depend on openmpi-default first. Please see the log file for port openmpi-default for details:
/opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_openmpi-default-1.7.5_3_a272d6c16ef1296938f908cc0944080d49c66489dfb63de25e65dcab22608f20-12289/openmpi-default/main.log Warning: Failed to execute portfile from registry for openmpi-default @1.7.5_3+gcc47 ---> Unable to uninstall openmpi-default @1.7.5_3+gcc47, the following ports depend on it: ---> openmpi @1.7.5_3 ---> petsc @3.5.3_1+accelerate+hwloc+openmpi ---> petsc @3.5.3_2+accelerate+hwloc+openmpi Error: port uninstall failed: Please uninstall the ports that depend on openmpi-default first.
So I uninstalled the three ports which depend on openmpi-default with success. Then I
ComerMacProRetina:~ comerduncan$ sudo port uninstall openmpi-default ---> Deactivating openmpi-default @1.7.5_3+gcc47 ---> Cleaning openmpi-default ---> Uninstalling openmpi-default @1.7.5_3+gcc47 ---> Cleaning openmpi-default
Then I installed openmpi-gcc49 as suggested and checked it:
ComerMacProRetina:~ comerduncan$ port installed | grep openmpi openmpi-gcc49 @1.7.5_3+fortran (active)
Is this what you had in mind? Assuming it is, I am going to try another build and will report back what happens.
Comer
On Thu, May 21, 2015 at 3:46 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
Thanks. It seems that MPI was built against a different C++ library. I now think that the package "openmpi-default" is wrong; there should be "openmpi-gcc49" instead. If so, then this is an error in the instructions we list in the osx-macports.cfg file. Can you uninstall openmpi-default, and install openmpi-gcc49 instead?
-erik
On Thu, May 21, 2015 at 3:28 PM, Comer Duncan comer.duncan@gmail.com wrote:
Erik,
Sure. Here you go.
ComerMacProRetina:Cactus comerduncan$ g++-mp-4.9 --version g++-mp-4.9 (MacPorts gcc49 4.9.2_1) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and
ComerMacProRetina:Cactus comerduncan$ /opt/local/bin/mpicxx --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix
I just did my usual macports maintenance script yesterday:
ComerMacProRetina:bin comerduncan$ cat portupdateupgrade echo '------------selfupdate------------------' sudo port selfupdate echo '------------outdated ports--------------' sudo port outdated echo '------------upgrade outdated ports------' sudo port upgrade outdated
Has macports stuff been polluted? I note that on May 20 the software update for mac osx included installed updates of Xcode to version 6.3.2 and Command Line Tools version 6.3. I am wondering whether the attempts at building Cactus intersected macports updates performed with updated Xcode/Command LIne Tools, so that the macport collection might be in somewhat of a conflicted state?
Comer
On Thu, May 21, 2015 at 3:16 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
I agree with you that the PAPI errors seem harmless.
The problem seems to be that something is wrong with vectorization. The error is reported inside a compiler-provided file. I don't know why these errors would now suddenly appear, as they were not there before. It looks as if something related to the C++ compiler changed.
This is quite annoying, since several of us tested this option list, and it worked for all of us...
Can you send us the output of
g++-mp-4.9 --version
and
/opt/local/bin/mpicxx --version
?
-erik
On Thu, May 21, 2015 at 2:44 PM, Comer Duncan comer.duncan@gmail.com wrote:
HI Frank,
I am running 10.10.3 (14D136) on a macbook pro with the following properties:
Version 10.10.3 (14D136) MacBook Pro (Retina, 15-inch, Mid 2014) Processor 2.5 Ghz Intel Core i7 (4 cores) 16 GB with 1TB SSD
I am up to date with macports (I do this every week or so).
I noticed complaints about papi but since builds don't crash with such complaints I forged ahead. I also note in the build logs multiple mentions (1405!) of Nonexistent include directories. How come such warnings are there in a new release? Maybe unrelated or not worth worrying about?
Please help.
Thanks.
Comer
On Thu, May 21, 2015 at 2:30 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Thu, May 21, 2015 at 01:52:25PM -0400, Comer Duncan wrote: > I have rebuilt Hilbert using the new detect.pl file suggested and get a > make crash but this time referring to seemingly different compile problems. > I have pasted the build4.log file to http://pastebin.com/kECKTkqr
Which Mac OS version do you have again? Could it be connected to this?
http://stackoverflow.com/questions/15963277/performance-api-on-mac-10-8
(there is no solution given there, but the symptoms fit)
Frank
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Well, the build crashes still. The log file is displayed in http://pastebin.com/zcj697X4 .
Comer
On Thu, May 21, 2015 at 4:19 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
Yes, this looks good.
-erik
On Thu, May 21, 2015 at 4:11 PM, Comer Duncan comer.duncan@gmail.com wrote:
Erik,
Ok, here goes. First,
ComerMacProRetina:~ comerduncan$ sudo port uninstall openmpi-default Password: ---> Unable to uninstall openmpi-default @1.7.5_3+gcc47, the following ports depend on it: ---> openmpi @1.7.5_3 ---> petsc @3.5.3_1+accelerate+hwloc+openmpi ---> petsc @3.5.3_2+accelerate+hwloc+openmpi Error: org.macports.uninstall for port openmpi-default returned: Please uninstall the ports that depend on openmpi-default first. Please see the log file for port openmpi-default for details:
/opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_openmpi-default-1.7.5_3_a272d6c16ef1296938f908cc0944080d49c66489dfb63de25e65dcab22608f20-12289/openmpi-default/main.log Warning: Failed to execute portfile from registry for openmpi-default @1.7.5_3+gcc47 ---> Unable to uninstall openmpi-default @1.7.5_3+gcc47, the following ports depend on it: ---> openmpi @1.7.5_3 ---> petsc @3.5.3_1+accelerate+hwloc+openmpi ---> petsc @3.5.3_2+accelerate+hwloc+openmpi Error: port uninstall failed: Please uninstall the ports that depend on openmpi-default first.
So I uninstalled the three ports which depend on openmpi-default with success. Then I
ComerMacProRetina:~ comerduncan$ sudo port uninstall openmpi-default ---> Deactivating openmpi-default @1.7.5_3+gcc47 ---> Cleaning openmpi-default ---> Uninstalling openmpi-default @1.7.5_3+gcc47 ---> Cleaning openmpi-default
Then I installed openmpi-gcc49 as suggested and checked it:
ComerMacProRetina:~ comerduncan$ port installed | grep openmpi openmpi-gcc49 @1.7.5_3+fortran (active)
Is this what you had in mind? Assuming it is, I am going to try another build and will report back what happens.
Comer
On Thu, May 21, 2015 at 3:46 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
Thanks. It seems that MPI was built against a different C++ library. I now think that the package "openmpi-default" is wrong; there should be "openmpi-gcc49" instead. If so, then this is an error in the instructions we list in the osx-macports.cfg file. Can you uninstall openmpi-default, and install openmpi-gcc49 instead?
-erik
On Thu, May 21, 2015 at 3:28 PM, Comer Duncan comer.duncan@gmail.com wrote:
Erik,
Sure. Here you go.
ComerMacProRetina:Cactus comerduncan$ g++-mp-4.9 --version g++-mp-4.9 (MacPorts gcc49 4.9.2_1) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and
ComerMacProRetina:Cactus comerduncan$ /opt/local/bin/mpicxx --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix
I just did my usual macports maintenance script yesterday:
ComerMacProRetina:bin comerduncan$ cat portupdateupgrade echo '------------selfupdate------------------' sudo port selfupdate echo '------------outdated ports--------------' sudo port outdated echo '------------upgrade outdated ports------' sudo port upgrade outdated
Has macports stuff been polluted? I note that on May 20 the software update for mac osx included installed updates of Xcode to version 6.3.2 and Command Line Tools version 6.3. I am wondering whether the attempts at building Cactus intersected macports updates performed with updated Xcode/Command LIne Tools, so that the macport collection might be in somewhat of a conflicted state?
Comer
On Thu, May 21, 2015 at 3:16 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Comer
I agree with you that the PAPI errors seem harmless.
The problem seems to be that something is wrong with vectorization. The error is reported inside a compiler-provided file. I don't know why these errors would now suddenly appear, as they were not there before. It looks as if something related to the C++ compiler changed.
This is quite annoying, since several of us tested this option list, and it worked for all of us...
Can you send us the output of
g++-mp-4.9 --version
and
/opt/local/bin/mpicxx --version
?
-erik
On Thu, May 21, 2015 at 2:44 PM, Comer Duncan comer.duncan@gmail.com wrote:
HI Frank,
I am running 10.10.3 (14D136) on a macbook pro with the following properties:
Version 10.10.3 (14D136) MacBook Pro (Retina, 15-inch, Mid 2014) Processor 2.5 Ghz Intel Core i7 (4 cores) 16 GB with 1TB SSD
I am up to date with macports (I do this every week or so).
I noticed complaints about papi but since builds don't crash with such complaints I forged ahead. I also note in the build logs multiple mentions (1405!) of Nonexistent include directories. How come such warnings are there in a new release? Maybe unrelated or not worth worrying about?
Please help.
Thanks.
Comer
On Thu, May 21, 2015 at 2:30 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
> On Thu, May 21, 2015 at 01:52:25PM -0400, Comer Duncan wrote: > > I have rebuilt Hilbert using the new detect.pl file suggested and > get a > > make crash but this time referring to seemingly different compile > problems. > > I have pasted the build4.log file to http://pastebin.com/kECKTkqr > > Which Mac OS version do you have again? Could it be connected to > this? > > > http://stackoverflow.com/questions/15963277/performance-api-on-mac-10-8 > > (there is no solution given there, but the symptoms fit) > > Frank > >
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Dear Corner and Erik:
After a while a decided to have the EinsteinToolkit compiled on my personal laptop. I did all from scratch.
* Latest versione of OSX (10.10.3) * Latest (clean) version of macports (MacPorts 2.3.3) sudo port install subversion sudo port install python27 sudo port select --set python python27 sudo port install py-numpy py-scipy sudo port install py-matplotlib sudo port install py-ipython sudo port select --set ipython ipython27 sudo port install pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 +fortran +gfortran openmpi openssl sudo port install py-h5py sudo port install gcc5 * Latest version of the EinsteinToolkit (Hilbert and dev) * I used the provided option list simfactory/mdb/optionlists/osx-macports.cfg
Basically I got a lot of warning (caused by the option -Wall) but they just have the effect to be difficult to see where are the problem.
* I was able to compile all the THORNS except “CarpetIOHDF5” and executable are created if I disable “Carpet/CarpetIOHDF5”
The failures are related to the compilations of just few files (see below)
I try to find out the reason of the failure but I failed. Hope this feedback may be useful to locate the problem.
TESTING with the thorn “Carpet/CarpetIOHDF5” disabled results in:
pushd /opt/local/bin/ ln -s mpirun-openmpi-mp mpirun popd
export OMP_NUM_THREADS=1
export TESTS_DIR=test_np2 export CCTK_TESTSUITE_RUN_PROCESSORS=2 make sim-testsuite PROMPT=no
export TESTS_DIR=test_np1 export CCTK_TESTSUITE_RUN_PROCESSORS=1 make sim-testsuite PROMPT=no
test_np1/sim/summary.log: Number of tested thorns -> 61 test_np1/sim/summary.log: Number of tests passed -> 175 test_np1/sim/summary.log: Number passed only to test_np1/sim/summary.log: Number failed -> 0
test_np2/sim/summary.log: Number of tested thorns -> 60 test_np2/sim/summary.log: Number of tests passed -> 207 test_np2/sim/summary.log: Number passed only to test_np2/sim/summary.log: Number failed -> 0
Roberto De Pietri
=================================================
Files after the command “make -i sim” in the directory: “sim/build/CarpetIOHDF5"
CarpetIOHDF5.cc GetAllActive.cc Input.cc.d Output.cc.d cctk_Bindings CarpetIOHDF5.cc.d GetAllActive.cc.d Input.cc.o OutputSlice.cc make.checked CarpetIOHDF5.cc.o Input.cc Output.cc OutputSlice.cc.d make.identity tycho:CarpetIOHDF5 depietri$
Meaning compilation failed for the source file:
** GetAllActive.cc ** Output.cc ** OutputSlice.cc
I have been able to obtain a working executable just with a minor modification on the include part of the the 3 source files.
Do not know if I did correctly.
======================================================= diff --git a/CarpetIOHDF5/src/GetAllActive.cc b/CarpetIOHDF5/src/GetAllActive.cc index bb92f4a..bb5d2da 100644 --- a/CarpetIOHDF5/src/GetAllActive.cc +++ b/CarpetIOHDF5/src/GetAllActive.cc @@ -8,8 +8,14 @@ @@*/
#include <cassert> - +#include <cstdlib> +#include <cstring> +#include <list> +#include <sstream> +#include <string> #include <vector> +#include <map> +#include <algorithm>
#include "cctk.h"
diff --git a/CarpetIOHDF5/src/Output.cc b/CarpetIOHDF5/src/Output.cc index ecef6b8..da82b87 100644 --- a/CarpetIOHDF5/src/Output.cc +++ b/CarpetIOHDF5/src/Output.cc @@ -1,7 +1,12 @@ #include <cassert> #include <cstdlib> #include <cstring> +#include <list> #include <sstream> +#include <string> +#include <vector> +#include <map> +#include <algorithm>
#include "cctk.h" #include "cctk_Arguments.h" diff --git a/CarpetIOHDF5/src/OutputSlice.cc b/CarpetIOHDF5/src/OutputSlice.cc index 43763fb..82a4db6 100644 --- a/CarpetIOHDF5/src/OutputSlice.cc +++ b/CarpetIOHDF5/src/OutputSlice.cc @@ -1,9 +1,12 @@ #include <cassert> -#include <cctype> -#include <climits> -#include <cmath> #include <cstdlib> #include <cstring> +#include <list> +#include <sstream> +#include <string> +#include <vector> +#include <map> +#include <algorithm>
#include <map> #include <string>
========================================================
Example errors for the compilation are: ============== MAIN ERROR MESSAGE ======================
COMPILING arrangements/Carpet/CarpetIOHDF5/src/Output.cc In file included from /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/x86intrin.h:29:0, from /opt/local/include/gcc49/c++/x86_64-apple-darwin14/bits/opt_random.h:33, from /opt/local/include/gcc49/c++/random:50, from /opt/local/include/gcc49/c++/bits/stl_algo.h:66, from /opt/local/include/gcc49/c++/algorithm:62, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetLib/src/defs.hh:6, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetLib/src/bbox.hh:10, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/configs/sim/bindings/include/bbox.hh:4, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/Carpet/src/functions.hh:17, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/Carpet/src/carpet_public.hh:8, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/configs/sim/bindings/include/carpet.hh:4, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh:11, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetIOHDF5/src/Output.cc:13: /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cvtsi32_si64(int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:64:54: error: can't convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i, 0); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function 'int _mm_cvtsi64_si32(__m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:107:53: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to 'int __builtin_ia32_vec_ext_v2si(__vector(2) int, int)' return __builtin_ia32_vec_ext_v2si ((__v2si)__i, 0); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_packs_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:146:69: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(8) char __builtin_ia32_packsswb(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_packsswb ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_packs_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:161:69: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(4) short int __builtin_ia32_packssdw(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_packssdw ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_packs_pu16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:176:69: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(8) char __builtin_ia32_packuswb(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_packuswb ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpackhi_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:190:70: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_punpckhbw(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_punpckhbw ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpackhi_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:204:70: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_punpckhwd(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_punpckhwd ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpackhi_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:218:70: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_punpckhdq(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_punpckhdq ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpacklo_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:232:70: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_punpcklbw(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_punpcklbw ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpacklo_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:246:70: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_punpcklwd(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_punpcklwd ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpacklo_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:260:70: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_punpckldq(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_punpckldq ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_add_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:273:66: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_paddb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_paddb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_add_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:286:66: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_paddw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_paddw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_add_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:299:66: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_paddd(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_paddd ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_add_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:318:66: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_paddq(__vector(1) long long int, __vector(1) long long int)' return (__m64) __builtin_ia32_paddq ((__v1di)__m1, (__v1di)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_adds_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:330:67: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_paddsb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_paddsb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_adds_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:344:67: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_paddsw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_paddsw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_adds_pu8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:358:68: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_paddusb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_paddusb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_adds_pu16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:372:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_paddusw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_paddusw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sub_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:385:66: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_psubb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_psubb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sub_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:398:66: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psubw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psubw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sub_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:411:66: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_psubd(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_psubd ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sub_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:430:66: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_psubq(__vector(1) long long int, __vector(1) long long int)' return (__m64) __builtin_ia32_psubq ((__v1di)__m1, (__v1di)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_subs_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:442:67: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_psubsb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_psubsb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_subs_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:456:67: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psubsw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psubsw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_subs_pu8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:470:68: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_psubusb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_psubusb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_subs_pu16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:484:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psubusw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psubusw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_madd_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:499:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(2) int __builtin_ia32_pmaddwd(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_pmaddwd ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_mulhi_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:513:67: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_pmulhw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_pmulhw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_mullo_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:527:67: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_pmullw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_pmullw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sll_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:540:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psllw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psllw ((__v4hi)__m, (__v4hi)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_slli_pi16(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:552:61: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psllwi(__vector(4) short int, int)' return (__m64) __builtin_ia32_psllwi ((__v4hi)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sll_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:565:68: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pslld(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_pslld ((__v2si)__m, (__v2si)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_slli_pi32(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:577:61: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pslldi(__vector(2) int, int)' return (__m64) __builtin_ia32_pslldi ((__v2si)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sll_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:590:68: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_psllq(__vector(1) long long int, __vector(1) long long int)' return (__m64) __builtin_ia32_psllq ((__v1di)__m, (__v1di)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_slli_si64(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:602:61: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_psllqi(__vector(1) long long int, int)' return (__m64) __builtin_ia32_psllqi ((__v1di)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sra_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:615:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psraw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psraw ((__v4hi)__m, (__v4hi)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srai_pi16(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:627:61: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psrawi(__vector(4) short int, int)' return (__m64) __builtin_ia32_psrawi ((__v4hi)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sra_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:640:68: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_psrad(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_psrad ((__v2si)__m, (__v2si)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srai_pi32(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:652:61: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_psradi(__vector(2) int, int)' return (__m64) __builtin_ia32_psradi ((__v2si)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srl_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:665:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psrlw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psrlw ((__v4hi)__m, (__v4hi)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srli_pi16(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:677:61: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psrlwi(__vector(4) short int, int)' return (__m64) __builtin_ia32_psrlwi ((__v4hi)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srl_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:690:68: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_psrld(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_psrld ((__v2si)__m, (__v2si)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srli_pi32(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:702:61: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_psrldi(__vector(2) int, int)' return (__m64) __builtin_ia32_psrldi ((__v2si)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srl_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:715:68: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_psrlq(__vector(1) long long int, __vector(1) long long int)' return (__m64) __builtin_ia32_psrlq ((__v1di)__m, (__v1di)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srli_si64(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:727:61: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_psrlqi(__vector(1) long long int, int)' return (__m64) __builtin_ia32_psrlqi ((__v1di)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_and_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:740:41: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pand(__vector(2) int, __vector(2) int)' return __builtin_ia32_pand (__m1, __m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_andnot_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:754:42: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pandn(__vector(2) int, __vector(2) int)' return __builtin_ia32_pandn (__m1, __m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_or_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:767:40: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_por(__vector(2) int, __vector(2) int)' return __builtin_ia32_por (__m1, __m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_xor_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:780:41: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pxor(__vector(2) int, __vector(2) int)' return __builtin_ia32_pxor (__m1, __m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpeq_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:794:68: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_pcmpeqb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_pcmpeqb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpgt_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:806:68: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_pcmpgtb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_pcmpgtb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpeq_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:820:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_pcmpeqw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_pcmpeqw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpgt_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:832:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_pcmpgtw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_pcmpgtw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpeq_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:846:68: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pcmpeqd(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_pcmpeqd ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpgt_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:858:68: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pcmpgtd(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_pcmpgtd ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_set_pi32(int, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:878:58: error: can't convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i0, __i1); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_set_pi16(short int, short int, short int, short int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:885:70: error: can't convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v4hi (__w0, __w1, __w2, __w3); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_set_pi8(char, char, char, char, char, char, char, char)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:894:35: error: can't convert between vector values of different size __b4, __b5, __b6, __b7); ^ In file included from /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/x86intrin.h:31:0, from /opt/local/include/gcc49/c++/x86_64-apple-darwin14/bits/opt_random.h:33, from /opt/local/include/gcc49/c++/random:50, from /opt/local/include/gcc49/c++/bits/stl_algo.h:66, . . . . . . Lot’s of message . . .
On 21 May 2015, at 22:45, Comer Duncan comer.duncan@gmail.com wrote:
Well, the build crashes still. The log file is displayed in http://pastebin.com/zcj697X4 .
Comer
On Thu, May 21, 2015 at 4:19 PM, Erik Schnetter schnetter@cct.lsu.edu wrote: Comer
Yes, this looks good.
-erik
On Thu, May 21, 2015 at 4:11 PM, Comer Duncan comer.duncan@gmail.com wrote: Erik,
Ok, here goes. First,
ComerMacProRetina:~ comerduncan$ sudo port uninstall openmpi-default Password: ---> Unable to uninstall openmpi-default @1.7.5_3+gcc47, the following ports depend on it: ---> openmpi @1.7.5_3 ---> petsc @3.5.3_1+accelerate+hwloc+openmpi ---> petsc @3.5.3_2+accelerate+hwloc+openmpi Error: org.macports.uninstall for port openmpi-default returned: Please uninstall the ports that depend on openmpi-default first. Please see the log file for port openmpi-default for details: /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_openmpi-default-1.7.5_3_a272d6c16ef1296938f908cc0944080d49c66489dfb63de25e65dcab22608f20-12289/openmpi-default/main.log Warning: Failed to execute portfile from registry for openmpi-default @1.7.5_3+gcc47 ---> Unable to uninstall openmpi-default @1.7.5_3+gcc47, the following ports depend on it: ---> openmpi @1.7.5_3 ---> petsc @3.5.3_1+accelerate+hwloc+openmpi ---> petsc @3.5.3_2+accelerate+hwloc+openmpi Error: port uninstall failed: Please uninstall the ports that depend on openmpi-default first.
So I uninstalled the three ports which depend on openmpi-default with success. Then I
ComerMacProRetina:~ comerduncan$ sudo port uninstall openmpi-default ---> Deactivating openmpi-default @1.7.5_3+gcc47 ---> Cleaning openmpi-default ---> Uninstalling openmpi-default @1.7.5_3+gcc47 ---> Cleaning openmpi-default
Then I installed openmpi-gcc49 as suggested and checked it:
ComerMacProRetina:~ comerduncan$ port installed | grep openmpi openmpi-gcc49 @1.7.5_3+fortran (active)
Is this what you had in mind? Assuming it is, I am going to try another build and will report back what happens.
Comer
On Thu, May 21, 2015 at 3:46 PM, Erik Schnetter schnetter@cct.lsu.edu wrote: Comer
Thanks. It seems that MPI was built against a different C++ library. I now think that the package "openmpi-default" is wrong; there should be "openmpi-gcc49" instead. If so, then this is an error in the instructions we list in the osx-macports.cfg file. Can you uninstall openmpi-default, and install openmpi-gcc49 instead?
-erik
On Thu, May 21, 2015 at 3:28 PM, Comer Duncan comer.duncan@gmail.com wrote: Erik,
Sure. Here you go.
ComerMacProRetina:Cactus comerduncan$ g++-mp-4.9 --version g++-mp-4.9 (MacPorts gcc49 4.9.2_1) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and
ComerMacProRetina:Cactus comerduncan$ /opt/local/bin/mpicxx --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix
I just did my usual macports maintenance script yesterday:
ComerMacProRetina:bin comerduncan$ cat portupdateupgrade echo '------------selfupdate------------------' sudo port selfupdate echo '------------outdated ports--------------' sudo port outdated echo '------------upgrade outdated ports------' sudo port upgrade outdated
Has macports stuff been polluted? I note that on May 20 the software update for mac osx included installed updates of Xcode to version 6.3.2 and Command Line Tools version 6.3. I am wondering whether the attempts at building Cactus intersected macports updates performed with updated Xcode/Command LIne Tools, so that the macport collection might be in somewhat of a conflicted state?
Comer
On Thu, May 21, 2015 at 3:16 PM, Erik Schnetter schnetter@cct.lsu.edu wrote: Comer
I agree with you that the PAPI errors seem harmless.
The problem seems to be that something is wrong with vectorization. The error is reported inside a compiler-provided file. I don't know why these errors would now suddenly appear, as they were not there before. It looks as if something related to the C++ compiler changed.
This is quite annoying, since several of us tested this option list, and it worked for all of us...
Can you send us the output of
g++-mp-4.9 --version
and
/opt/local/bin/mpicxx --version
?
-erik
On Thu, May 21, 2015 at 2:44 PM, Comer Duncan comer.duncan@gmail.com wrote: HI Frank,
I am running 10.10.3 (14D136) on a macbook pro with the following properties:
Version 10.10.3 (14D136) MacBook Pro (Retina, 15-inch, Mid 2014) Processor 2.5 Ghz Intel Core i7 (4 cores) 16 GB with 1TB SSD
I am up to date with macports (I do this every week or so).
I noticed complaints about papi but since builds don't crash with such complaints I forged ahead. I also note in the build logs multiple mentions (1405!) of Nonexistent include directories. How come such warnings are there in a new release? Maybe unrelated or not worth worrying about?
Please help.
Thanks.
Comer
On Thu, May 21, 2015 at 2:30 PM, Frank Loeffler knarf@cct.lsu.edu wrote: On Thu, May 21, 2015 at 01:52:25PM -0400, Comer Duncan wrote:
I have rebuilt Hilbert using the new detect.pl file suggested and get a make crash but this time referring to seemingly different compile problems. I have pasted the build4.log file to http://pastebin.com/kECKTkqr
Which Mac OS version do you have again? Could it be connected to this?
http://stackoverflow.com/questions/15963277/performance-api-on-mac-10-8
(there is no solution given there, but the symptoms fit)
Frank
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
------------------------------------------------------------------ Roberto De Pietri e-mail:roberto.depietri@fis.unipr.it Dipartimento di Fisica http://www.fis.unipr.it/~roberto.depietri Universita' di Parma tel: +39 (0521) 905280 Via G.P.Usberti 7/A fax: +39 (0521) 905223 I-43100 PARMA --- ITALY
On 22 May 2015, at 12:44, Roberto De Pietri roberto.depietri@unipr.it wrote:
Dear Corner and Erik:
After a while a decided to have the EinsteinToolkit compiled on my personal laptop. I did all from scratch.
- Latest versione of OSX (10.10.3)
- Latest (clean) version of macports (MacPorts 2.3.3) sudo port install subversion sudo port install python27 sudo port select --set python python27 sudo port install py-numpy py-scipy sudo port install py-matplotlib sudo port install py-ipython sudo port select --set ipython ipython27 sudo port install pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 +fortran +gfortran openmpi openssl sudo port install py-h5py sudo port install gcc5
- Latest version of the EinsteinToolkit (Hilbert and dev)
- I used the provided option list simfactory/mdb/optionlists/osx-macports.cfg
Hi Roberto,
What we have tested carefully is to use exactly the list of ports in the osx-macports.cfg config file. I tested this by moving my usual /opt/local out of the way, and installing MacPorts from scratch using exactly the "port install" command listed in the optionlist.
Unfortunately, having multiple versions of things like compilers and MPI in the places that Cactus searches for them (e.g. /opt/local) generically causes problems when compiling software from source. I notice that you have used exactly this command line (sudo port install pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 +fortran +gfortran openmpi openssl), but you also have other ports installed, and it's possible that some of these might conflict during the autodetection stage, causing some undesirable mixtures. My main suspicion, looking at your compilation errors, is something to do with vectorisation and HDF5. You have installed py-h5py, which may well have has pulled in a different HDF5 library. You may now have more than one HDF5 library installed, and it's possible that this is causing confusion. What is the output of
port installed "*hdf5*"
Am I correct in understanding that by adding those additional include files, you were able to compile CarpetIOHDF5? Maybe it's pulling in an hdf5.h from a different version of hdf5 than is expected?
Basically I got a lot of warning (caused by the option -Wall) but they just have the effect to be difficult to see where are the problem.
- I was able to compile all the THORNS except “CarpetIOHDF5” and executable are
created if I disable “Carpet/CarpetIOHDF5”
The failures are related to the compilations of just few files (see below)
I try to find out the reason of the failure but I failed. Hope this feedback may be useful to locate the problem.
TESTING with the thorn “Carpet/CarpetIOHDF5” disabled results in:
pushd /opt/local/bin/ ln -s mpirun-openmpi-mp mpirun popd
export OMP_NUM_THREADS=1
export TESTS_DIR=test_np2 export CCTK_TESTSUITE_RUN_PROCESSORS=2 make sim-testsuite PROMPT=no
export TESTS_DIR=test_np1 export CCTK_TESTSUITE_RUN_PROCESSORS=1 make sim-testsuite PROMPT=no
test_np1/sim/summary.log: Number of tested thorns -> 61 test_np1/sim/summary.log: Number of tests passed -> 175 test_np1/sim/summary.log: Number passed only to test_np1/sim/summary.log: Number failed -> 0
test_np2/sim/summary.log: Number of tested thorns -> 60 test_np2/sim/summary.log: Number of tests passed -> 207 test_np2/sim/summary.log: Number passed only to test_np2/sim/summary.log: Number failed -> 0
Roberto De Pietri
=================================================
Files after the command “make -i sim” in the directory: “sim/build/CarpetIOHDF5"
CarpetIOHDF5.cc GetAllActive.cc Input.cc.d Output.cc.d cctk_Bindings CarpetIOHDF5.cc.d GetAllActive.cc.d Input.cc.o OutputSlice.cc make.checked CarpetIOHDF5.cc.o Input.cc Output.cc OutputSlice.cc.d make.identity tycho:CarpetIOHDF5 depietri$
Meaning compilation failed for the source file:
** GetAllActive.cc ** Output.cc ** OutputSlice.cc
I have been able to obtain a working executable just with a minor modification on the include part of the the 3 source files.
Do not know if I did correctly.
======================================================= diff --git a/CarpetIOHDF5/src/GetAllActive.cc b/CarpetIOHDF5/src/GetAllActive.cc index bb92f4a..bb5d2da 100644 --- a/CarpetIOHDF5/src/GetAllActive.cc +++ b/CarpetIOHDF5/src/GetAllActive.cc @@ -8,8 +8,14 @@ @@*/
#include <cassert>
+#include <cstdlib> +#include <cstring> +#include <list> +#include <sstream> +#include <string> #include <vector> +#include <map> +#include <algorithm>
#include "cctk.h"
diff --git a/CarpetIOHDF5/src/Output.cc b/CarpetIOHDF5/src/Output.cc index ecef6b8..da82b87 100644 --- a/CarpetIOHDF5/src/Output.cc +++ b/CarpetIOHDF5/src/Output.cc @@ -1,7 +1,12 @@ #include <cassert> #include <cstdlib> #include <cstring> +#include <list> #include <sstream> +#include <string> +#include <vector> +#include <map> +#include <algorithm>
#include "cctk.h" #include "cctk_Arguments.h" diff --git a/CarpetIOHDF5/src/OutputSlice.cc b/CarpetIOHDF5/src/OutputSlice.cc index 43763fb..82a4db6 100644 --- a/CarpetIOHDF5/src/OutputSlice.cc +++ b/CarpetIOHDF5/src/OutputSlice.cc @@ -1,9 +1,12 @@ #include <cassert> -#include <cctype> -#include <climits> -#include <cmath> #include <cstdlib> #include <cstring> +#include <list> +#include <sstream> +#include <string> +#include <vector> +#include <map> +#include <algorithm>
#include <map> #include <string>
========================================================
Example errors for the compilation are: ============== MAIN ERROR MESSAGE ======================
COMPILING arrangements/Carpet/CarpetIOHDF5/src/Output.cc In file included from /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/x86intrin.h:29:0, from /opt/local/include/gcc49/c++/x86_64-apple-darwin14/bits/opt_random.h:33, from /opt/local/include/gcc49/c++/random:50, from /opt/local/include/gcc49/c++/bits/stl_algo.h:66, from /opt/local/include/gcc49/c++/algorithm:62, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetLib/src/defs.hh:6, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetLib/src/bbox.hh:10, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/configs/sim/bindings/include/bbox.hh:4, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/Carpet/src/functions.hh:17, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/Carpet/src/carpet_public.hh:8, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/configs/sim/bindings/include/carpet.hh:4, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh:11, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetIOHDF5/src/Output.cc:13: /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cvtsi32_si64(int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:64:54: error: can't convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i, 0); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function 'int _mm_cvtsi64_si32(__m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:107:53: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to 'int __builtin_ia32_vec_ext_v2si(__vector(2) int, int)' return __builtin_ia32_vec_ext_v2si ((__v2si)__i, 0); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_packs_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:146:69: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(8) char __builtin_ia32_packsswb(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_packsswb ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_packs_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:161:69: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(4) short int __builtin_ia32_packssdw(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_packssdw ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_packs_pu16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:176:69: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(8) char __builtin_ia32_packuswb(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_packuswb ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpackhi_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:190:70: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_punpckhbw(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_punpckhbw ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpackhi_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:204:70: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_punpckhwd(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_punpckhwd ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpackhi_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:218:70: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_punpckhdq(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_punpckhdq ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpacklo_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:232:70: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_punpcklbw(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_punpcklbw ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpacklo_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:246:70: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_punpcklwd(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_punpcklwd ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_unpacklo_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:260:70: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_punpckldq(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_punpckldq ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_add_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:273:66: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_paddb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_paddb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_add_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:286:66: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_paddw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_paddw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_add_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:299:66: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_paddd(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_paddd ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_add_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:318:66: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_paddq(__vector(1) long long int, __vector(1) long long int)' return (__m64) __builtin_ia32_paddq ((__v1di)__m1, (__v1di)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_adds_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:330:67: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_paddsb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_paddsb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_adds_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:344:67: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_paddsw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_paddsw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_adds_pu8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:358:68: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_paddusb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_paddusb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_adds_pu16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:372:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_paddusw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_paddusw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sub_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:385:66: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_psubb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_psubb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sub_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:398:66: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psubw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psubw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sub_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:411:66: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_psubd(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_psubd ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sub_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:430:66: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_psubq(__vector(1) long long int, __vector(1) long long int)' return (__m64) __builtin_ia32_psubq ((__v1di)__m1, (__v1di)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_subs_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:442:67: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_psubsb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_psubsb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_subs_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:456:67: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psubsw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psubsw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_subs_pu8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:470:68: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_psubusb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_psubusb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_subs_pu16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:484:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psubusw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psubusw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_madd_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:499:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(2) int __builtin_ia32_pmaddwd(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_pmaddwd ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_mulhi_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:513:67: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_pmulhw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_pmulhw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_mullo_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:527:67: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_pmullw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_pmullw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sll_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:540:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psllw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psllw ((__v4hi)__m, (__v4hi)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_slli_pi16(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:552:61: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psllwi(__vector(4) short int, int)' return (__m64) __builtin_ia32_psllwi ((__v4hi)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sll_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:565:68: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pslld(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_pslld ((__v2si)__m, (__v2si)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_slli_pi32(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:577:61: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pslldi(__vector(2) int, int)' return (__m64) __builtin_ia32_pslldi ((__v2si)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sll_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:590:68: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_psllq(__vector(1) long long int, __vector(1) long long int)' return (__m64) __builtin_ia32_psllq ((__v1di)__m, (__v1di)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_slli_si64(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:602:61: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_psllqi(__vector(1) long long int, int)' return (__m64) __builtin_ia32_psllqi ((__v1di)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sra_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:615:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psraw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psraw ((__v4hi)__m, (__v4hi)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srai_pi16(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:627:61: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psrawi(__vector(4) short int, int)' return (__m64) __builtin_ia32_psrawi ((__v4hi)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_sra_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:640:68: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_psrad(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_psrad ((__v2si)__m, (__v2si)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srai_pi32(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:652:61: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_psradi(__vector(2) int, int)' return (__m64) __builtin_ia32_psradi ((__v2si)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srl_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:665:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psrlw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_psrlw ((__v4hi)__m, (__v4hi)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srli_pi16(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:677:61: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_psrlwi(__vector(4) short int, int)' return (__m64) __builtin_ia32_psrlwi ((__v4hi)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srl_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:690:68: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_psrld(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_psrld ((__v2si)__m, (__v2si)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srli_pi32(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:702:61: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_psrldi(__vector(2) int, int)' return (__m64) __builtin_ia32_psrldi ((__v2si)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srl_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:715:68: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_psrlq(__vector(1) long long int, __vector(1) long long int)' return (__m64) __builtin_ia32_psrlq ((__v1di)__m, (__v1di)__count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_srli_si64(__m64, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:727:61: error: cannot convert '__v1di {aka long long int}' to '__vector(1) long long int' for argument '1' to '__vector(1) long long int __builtin_ia32_psrlqi(__vector(1) long long int, int)' return (__m64) __builtin_ia32_psrlqi ((__v1di)__m, __count); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_and_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:740:41: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pand(__vector(2) int, __vector(2) int)' return __builtin_ia32_pand (__m1, __m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_andnot_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:754:42: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pandn(__vector(2) int, __vector(2) int)' return __builtin_ia32_pandn (__m1, __m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_or_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:767:40: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_por(__vector(2) int, __vector(2) int)' return __builtin_ia32_por (__m1, __m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_xor_si64(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:780:41: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pxor(__vector(2) int, __vector(2) int)' return __builtin_ia32_pxor (__m1, __m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpeq_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:794:68: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_pcmpeqb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_pcmpeqb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpgt_pi8(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:806:68: error: cannot convert '__v8qi {aka char}' to '__vector(8) char' for argument '1' to '__vector(8) char __builtin_ia32_pcmpgtb(__vector(8) char, __vector(8) char)' return (__m64) __builtin_ia32_pcmpgtb ((__v8qi)__m1, (__v8qi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpeq_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:820:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_pcmpeqw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_pcmpeqw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpgt_pi16(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:832:68: error: cannot convert '__v4hi {aka short int}' to '__vector(4) short int' for argument '1' to '__vector(4) short int __builtin_ia32_pcmpgtw(__vector(4) short int, __vector(4) short int)' return (__m64) __builtin_ia32_pcmpgtw ((__v4hi)__m1, (__v4hi)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpeq_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:846:68: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pcmpeqd(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_pcmpeqd ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_cmpgt_pi32(__m64, __m64)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:858:68: error: cannot convert '__m64 {aka int}' to '__vector(2) int' for argument '1' to '__vector(2) int __builtin_ia32_pcmpgtd(__vector(2) int, __vector(2) int)' return (__m64) __builtin_ia32_pcmpgtd ((__v2si)__m1, (__v2si)__m2); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_set_pi32(int, int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:878:58: error: can't convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i0, __i1); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_set_pi16(short int, short int, short int, short int)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:885:70: error: can't convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v4hi (__w0, __w1, __w2, __w3); ^ /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h: In function '__m64 _mm_set_pi8(char, char, char, char, char, char, char, char)': /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h:894:35: error: can't convert between vector values of different size __b4, __b5, __b6, __b7); ^ In file included from /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/x86intrin.h:31:0, from /opt/local/include/gcc49/c++/x86_64-apple-darwin14/bits/opt_random.h:33, from /opt/local/include/gcc49/c++/random:50, from /opt/local/include/gcc49/c++/bits/stl_algo.h:66, . . . . . . Lot’s of message . . .
On 21 May 2015, at 22:45, Comer Duncan comer.duncan@gmail.com wrote:
Well, the build crashes still. The log file is displayed in http://pastebin.com/zcj697X4 .
Comer
On Thu, May 21, 2015 at 4:19 PM, Erik Schnetter schnetter@cct.lsu.edu wrote: Comer
Yes, this looks good.
-erik
On Thu, May 21, 2015 at 4:11 PM, Comer Duncan comer.duncan@gmail.com wrote: Erik,
Ok, here goes. First,
ComerMacProRetina:~ comerduncan$ sudo port uninstall openmpi-default Password: ---> Unable to uninstall openmpi-default @1.7.5_3+gcc47, the following ports depend on it: ---> openmpi @1.7.5_3 ---> petsc @3.5.3_1+accelerate+hwloc+openmpi ---> petsc @3.5.3_2+accelerate+hwloc+openmpi Error: org.macports.uninstall for port openmpi-default returned: Please uninstall the ports that depend on openmpi-default first. Please see the log file for port openmpi-default for details: /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_openmpi-default-1.7.5_3_a272d6c16ef1296938f908cc0944080d49c66489dfb63de25e65dcab22608f20-12289/openmpi-default/main.log Warning: Failed to execute portfile from registry for openmpi-default @1.7.5_3+gcc47 ---> Unable to uninstall openmpi-default @1.7.5_3+gcc47, the following ports depend on it: ---> openmpi @1.7.5_3 ---> petsc @3.5.3_1+accelerate+hwloc+openmpi ---> petsc @3.5.3_2+accelerate+hwloc+openmpi Error: port uninstall failed: Please uninstall the ports that depend on openmpi-default first.
So I uninstalled the three ports which depend on openmpi-default with success. Then I
ComerMacProRetina:~ comerduncan$ sudo port uninstall openmpi-default ---> Deactivating openmpi-default @1.7.5_3+gcc47 ---> Cleaning openmpi-default ---> Uninstalling openmpi-default @1.7.5_3+gcc47 ---> Cleaning openmpi-default
Then I installed openmpi-gcc49 as suggested and checked it:
ComerMacProRetina:~ comerduncan$ port installed | grep openmpi openmpi-gcc49 @1.7.5_3+fortran (active)
Is this what you had in mind? Assuming it is, I am going to try another build and will report back what happens.
Comer
On Thu, May 21, 2015 at 3:46 PM, Erik Schnetter schnetter@cct.lsu.edu wrote: Comer
Thanks. It seems that MPI was built against a different C++ library. I now think that the package "openmpi-default" is wrong; there should be "openmpi-gcc49" instead. If so, then this is an error in the instructions we list in the osx-macports.cfg file. Can you uninstall openmpi-default, and install openmpi-gcc49 instead?
-erik
On Thu, May 21, 2015 at 3:28 PM, Comer Duncan comer.duncan@gmail.com wrote: Erik,
Sure. Here you go.
ComerMacProRetina:Cactus comerduncan$ g++-mp-4.9 --version g++-mp-4.9 (MacPorts gcc49 4.9.2_1) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and
ComerMacProRetina:Cactus comerduncan$ /opt/local/bin/mpicxx --version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix
I just did my usual macports maintenance script yesterday:
ComerMacProRetina:bin comerduncan$ cat portupdateupgrade echo '------------selfupdate------------------' sudo port selfupdate echo '------------outdated ports--------------' sudo port outdated echo '------------upgrade outdated ports------' sudo port upgrade outdated
Has macports stuff been polluted? I note that on May 20 the software update for mac osx included installed updates of Xcode to version 6.3.2 and Command Line Tools version 6.3. I am wondering whether the attempts at building Cactus intersected macports updates performed with updated Xcode/Command LIne Tools, so that the macport collection might be in somewhat of a conflicted state?
Comer
On Thu, May 21, 2015 at 3:16 PM, Erik Schnetter schnetter@cct.lsu.edu wrote: Comer
I agree with you that the PAPI errors seem harmless.
The problem seems to be that something is wrong with vectorization. The error is reported inside a compiler-provided file. I don't know why these errors would now suddenly appear, as they were not there before. It looks as if something related to the C++ compiler changed.
This is quite annoying, since several of us tested this option list, and it worked for all of us...
Can you send us the output of
g++-mp-4.9 --version
and
/opt/local/bin/mpicxx --version
?
-erik
On Thu, May 21, 2015 at 2:44 PM, Comer Duncan comer.duncan@gmail.com wrote: HI Frank,
I am running 10.10.3 (14D136) on a macbook pro with the following properties:
Version 10.10.3 (14D136) MacBook Pro (Retina, 15-inch, Mid 2014) Processor 2.5 Ghz Intel Core i7 (4 cores) 16 GB with 1TB SSD
I am up to date with macports (I do this every week or so).
I noticed complaints about papi but since builds don't crash with such complaints I forged ahead. I also note in the build logs multiple mentions (1405!) of Nonexistent include directories. How come such warnings are there in a new release? Maybe unrelated or not worth worrying about?
Please help.
Thanks.
Comer
On Thu, May 21, 2015 at 2:30 PM, Frank Loeffler knarf@cct.lsu.edu wrote: On Thu, May 21, 2015 at 01:52:25PM -0400, Comer Duncan wrote:
I have rebuilt Hilbert using the new detect.pl file suggested and get a make crash but this time referring to seemingly different compile problems. I have pasted the build4.log file to http://pastebin.com/kECKTkqr
Which Mac OS version do you have again? Could it be connected to this?
http://stackoverflow.com/questions/15963277/performance-api-on-mac-10-8
(there is no solution given there, but the symptoms fit)
Frank
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Roberto De Pietri e-mail:roberto.depietri@fis.unipr.it Dipartimento di Fisica http://www.fis.unipr.it/~roberto.depietri Universita' di Parma tel: +39 (0521) 905280 Via G.P.Usberti 7/A fax: +39 (0521) 905223 I-43100 PARMA --- ITALY
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi Ian:
Thanks for the answer. I followed exactly your procedure and I was very surprised of having a failing compilation. Than I starting tracing back the problem. * All the thorns except one were compiling correctly. * The failing thorn was CarpetIOHDF5 and of the 5 source files present only 3 failed * The error was very strange because the only real problem was related to a system include “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h” and was related to conversion using AVX intel intrinsic. The error were of the type:
error: can’t convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
I was think about bad iteration between include files. Something like macro expansion of system file happening after incluse of application macro.
* I decide to give a try to just change the system include on the top of the failing source files to looks like the compiling one. Basicaly I just added #include <cstdlib> #include <cstring> #include <list> #include <sstream> #include <string> #include <vector> #include <map> #include <algorithm> on the top of the 3 failing files
* with these limited changes to just 3 files I obtained a compiling executable that passed the whole testsuite.
==============================================================
Here is the results about the active hdf5 library in mac ports on my machine.
tycho:python_util depietri$ port installed "*hdf5*" The following ports are currently installed: hdf5 @1.8.15_0+cxx hdf5 @1.8.15_0+cxx+fortran+gfortran (active)
On the sequence of installing ports the only difference was in the order, that is I installed subversion and python before the sequence in osx-macports.cfg
With my change I got /opt/local/include/gcc49/c++/algorithm include before /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh that the other way around.
This is my understanding. The thing that happens in the two files that successfully compiled.
Here is failed include sequence:
COMPILING arrangements/Carpet/CarpetIOHDF5/src/Output.cc In file included from /opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/x86intrin.h:29:0, from /opt/local/include/gcc49/c++/x86_64-apple-darwin14/bits/opt_random.h:33, from /opt/local/include/gcc49/c++/random:50, from /opt/local/include/gcc49/c++/bits/stl_algo.h:66, from /opt/local/include/gcc49/c++/algorithm:62, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetLib/src/defs.hh:6, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetLib/src/bbox.hh:10, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/configs/sim/bindings/include/bbox.hh:4, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/Carpet/src/functions.hh:17, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/Carpet/src/carpet_public.hh:8, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/configs/sim/bindings/include/carpet.hh:4, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh:11, from /Users/depietri/EinsteinToolkit/ET_dev/Cactus/arrangements/Carpet/CarpetIOHDF5/src/Output.cc:13:
Roberto
On 22 May 2015, at 15:35, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 12:44, Roberto De Pietri roberto.depietri@unipr.it wrote:
Dear Corner and Erik:
After a while a decided to have the EinsteinToolkit compiled on my personal laptop. I did all from scratch.
- Latest versione of OSX (10.10.3)
- Latest (clean) version of macports (MacPorts 2.3.3) sudo port install subversion sudo port install python27 sudo port select --set python python27 sudo port install py-numpy py-scipy sudo port install py-matplotlib sudo port install py-ipython sudo port select --set ipython ipython27 sudo port install pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 +fortran +gfortran openmpi openssl sudo port install py-h5py sudo port install gcc5
- Latest version of the EinsteinToolkit (Hilbert and dev)
- I used the provided option list simfactory/mdb/optionlists/osx-macports.cfg
Hi Roberto,
What we have tested carefully is to use exactly the list of ports in the osx-macports.cfg config file. I tested this by moving my usual /opt/local out of the way, and installing MacPorts from scratch using exactly the "port install" command listed in the optionlist.
Unfortunately, having multiple versions of things like compilers and MPI in the places that Cactus searches for them (e.g. /opt/local) generically causes problems when compiling software from source. I notice that you have used exactly this command line (sudo port install pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 +fortran +gfortran openmpi openssl), but you also have other ports installed, and it's possible that some of these might conflict during the autodetection stage, causing some undesirable mixtures. My main suspicion, looking at your compilation errors, is something to do with vectorisation and HDF5. You have installed py-h5py, which may well have has pulled in a different HDF5 library. You may now have more than one HDF5 library installed, and it's possible that this is causing confusion. What is the output of
port installed "*hdf5*"
Am I correct in understanding that by adding those additional include files, you were able to compile CarpetIOHDF5? Maybe it's pulling in an hdf5.h from a different version of hdf5 than is expected?
------------------------------------------------------------------ Roberto De Pietri e-mail:roberto.depietri@fis.unipr.it Dipartimento di Fisica http://www.fis.unipr.it/~roberto.depietri Universita' di Parma tel: +39 (0521) 905280 Via G.P.Usberti 7/A fax: +39 (0521) 905223 I-43100 PARMA --- ITALY
On 22 May 2015, at 16:10, Roberto De Pietri roberto.depietri@unipr.it wrote:
Hi Ian:
Thanks for the answer. I followed exactly your procedure and I was very surprised of having a failing compilation. Than I starting tracing back the problem.
- All the thorns except one were compiling correctly.
- The failing thorn was CarpetIOHDF5 and of the 5 source files present only 3 failed
- The error was very strange because the only real problem was related to
a system include “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h” and was related to conversion using AVX intel intrinsic. The error were of the type:
error: can’t convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
There is a stackoverflow post (http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-... ) which describes a similar problem, which I haven't studied in depth, but they seem to suggest that it's a bug in gcc, and that setting --std=gnu++11 instead of --std=c++11 in CXXFLAGS will work around the problem. We currently have
CXXFLAGS = -g -std=c++14
so I'm guessing that changing this to
CXXFLAGS = -g -std=gnu++14
might have the same effect.
What I don't understand is why we didn't pick this up in testing. I successfully compiled the whole ET using exactly that set of MacPorts packages and the optionlist before the release, and the gcc49 macports package hasn't been updated since 4 weeks ago.
When you say you followed exactly my procedure, do you mean that you get the above compilation problem even when you have only the ports listed in the optionlist installed, and have not installed anything else, such as gcc5 or the python packages?
On 22 May 2015, at 18:34, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 16:10, Roberto De Pietri roberto.depietri@unipr.it wrote:
Hi Ian:
Thanks for the answer. I followed exactly your procedure and I was very surprised of having a failing compilation. Than I starting tracing back the problem.
- All the thorns except one were compiling correctly.
- The failing thorn was CarpetIOHDF5 and of the 5 source files present only 3 failed
- The error was very strange because the only real problem was related to
a system include “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h” and was related to conversion using AVX intel intrinsic. The error were of the type:
error: can’t convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
There is a stackoverflow post (http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-... ) which describes a similar problem, which I haven't studied in depth, but they seem to suggest that it's a bug in gcc, and that setting --std=gnu++11 instead of --std=c++11 in CXXFLAGS will work around the problem. We currently have
CXXFLAGS = -g -std=c++14
so I'm guessing that changing this to
CXXFLAGS = -g -std=gnu++14
might have the same effect.
What I don't understand is why we didn't pick this up in testing. I successfully compiled the whole ET using exactly that set of MacPorts packages and the optionlist before the release, and the gcc49 macports package hasn't been updated since 4 weeks ago.
I should add that I tested it on 10.9.5, since I haven't been brave enough to update to 10.10 yet. I think Erik was testing on 10.10, but he can confirm that.
On Fri, May 22, 2015 at 12:38 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 18:34, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 16:10, Roberto De Pietri roberto.depietri@unipr.it wrote:
Hi Ian:
Thanks for the answer. I followed exactly your procedure and I was very surprised of having a failing compilation. Than I starting tracing back the problem.
- All the thorns except one were compiling correctly.
- The failing thorn was CarpetIOHDF5 and of the 5 source files present
only 3 failed
- The error was very strange because the only real problem was related to
a system include “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h” and was related to conversion using AVX intel intrinsic. The error were of the type:
error: can’t convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
There is a stackoverflow post ( http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-... ) which describes a similar problem, which I haven't studied in depth, but they seem to suggest that it's a bug in gcc, and that setting --std=gnu++11 instead of --std=c++11 in CXXFLAGS will work around the problem.
Yes, it seems that this describes the problem we're having. GCC uses
__attribute__ to provide certain language extensions, e.g. for vectorization. These are not optional declarations -- these modify function definition and can't just be omitted.
And HDF5 does just that: it #defines __attribute__ to be empty (file H5api_adpt.h, near the beginning) if the file is included from C++. I have no idea why they would think this is legal, or why they would think this is even a good idea. We use __attribute__ in Cactus (after checking via autoconf whether it is supported) for a variety of optimizations and security checks.
I would try adding the line
#undef __attribute__
right after (below) any line that says
#include <hdf5.h>
to undo (part of) the damage that HDF5 does. We should also complain to the HDF5 authors.
-erik
We currently have
CXXFLAGS = -g -std=c++14
so I'm guessing that changing this to
CXXFLAGS = -g -std=gnu++14
might have the same effect.
What I don't understand is why we didn't pick this up in testing. I successfully compiled the whole ET using exactly that set of MacPorts packages and the optionlist before the release, and the gcc49 macports package hasn't been updated since 4 weeks ago.
I should add that I tested it on 10.9.5, since I haven't been brave enough to update to 10.10 yet. I think Erik was testing on 10.10, but he can confirm that.
-- Ian Hinder http://members.aei.mpg.de/ianhin
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 23 May 2015, at 05:08, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Fri, May 22, 2015 at 12:38 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 18:34, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 16:10, Roberto De Pietri roberto.depietri@unipr.it wrote:
Hi Ian:
Thanks for the answer. I followed exactly your procedure and I was very surprised of having a failing compilation. Than I starting tracing back the problem.
- All the thorns except one were compiling correctly.
- The failing thorn was CarpetIOHDF5 and of the 5 source files present only 3 failed
- The error was very strange because the only real problem was related to
a system include “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h” and was related to conversion using AVX intel intrinsic. The error were of the type:
error: can’t convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
There is a stackoverflow post (http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-... ) which describes a similar problem, which I haven't studied in depth, but they seem to suggest that it's a bug in gcc, and that setting --std=gnu++11 instead of --std=c++11 in CXXFLAGS will work around the problem.
Yes, it seems that this describes the problem we're having. GCC uses __attribute__ to provide certain language extensions, e.g. for vectorization. These are not optional declarations -- these modify function definition and can't just be omitted.
And HDF5 does just that: it #defines __attribute__ to be empty (file H5api_adpt.h, near the beginning) if the file is included from C++. I have no idea why they would think this is legal, or why they would think this is even a good idea. We use __attribute__ in Cactus (after checking via autoconf whether it is supported) for a variety of optimizations and security checks.
I would try adding the line
#undef __attribute__
right after (below) any line that says
#include <hdf5.h>
to undo (part of) the damage that HDF5 does. We should also complain to the HDF5 authors.
So to summarise:
– HDF5 is undefining __attribute__, and this is a bug in hdf5. – In the stack overflow post, argp.h is undefining __attribute__, so this is a bug in glibc
Is that correct? My suggestion to try --std=gnu++11 in CXXFLAGS won't fix the problem in the HFD5 header; it would only affect the argp.h problem, which doesn't apply to us.
Digging a bit deeper, it seems that we have been bitten (again) by trying to track a moving target. The HDF5 MacPorts port was updated from 1.8.14 to 1.8.15 on 16-May-2015 (https://trac.macports.org/log/trunk/dports/science/hdf5/Portfile), 2 days before the ET release, and after the release branches had been created and the final testing had been done. Note that this also happened with OpenMPI a few days before, introducing a critical regression which we were able to work around in time.
The responsible commit in HDF5 seems to be this one:
https://github.com/live-clones/hdf5/commit/b283f087e32fb99023650240ef8290a3f...
They were previously undefining __attribute__ only in H5private.h, which is included by hdf5 source files, but not from the public api used by user code, and this commit moves this definition into a public header file included by user code. Erik, do you want to contact the developers, since you understand this better than I do?
I think the most sensible workaround for us would be set HDF5_DIR = BUILD in osx-macports.cfg, since the current macports version is broken. MacPorts has a single tree, they don't split into stable and unstable branches, presumably due to lack of resources. The same is true of homebrew; presumably they will also update to 1.8.15 at some point, so maybe we should build HDF5 for homebrew as well. The Cactus-provided version in ExternalLibraries is 1.8.14.
Hi Ian,
I have elected to get the development version and have successfully done a build only changing the osx-macports.cfg to replace the default HDF5 = line to HDF5 = BUILD, as you suggested earlier today. I am now running the static-tov test and see the beginning of reasonable output with the plots of rho max and alp looking ok.
Thanks for the help from you Erik, Roberto, and Frank. Should the macports version of HDF5 work compatibly with Cactus please let me know.
Best regards,
Comer
On Sat, May 23, 2015 at 1:06 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 23 May 2015, at 05:08, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Fri, May 22, 2015 at 12:38 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 18:34, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 16:10, Roberto De Pietri roberto.depietri@unipr.it wrote:
Hi Ian:
Thanks for the answer. I followed exactly your procedure and I was very surprised of having a failing compilation. Than I starting tracing back the problem.
- All the thorns except one were compiling correctly.
- The failing thorn was CarpetIOHDF5 and of the 5 source files present
only 3 failed
- The error was very strange because the only real problem was related to
a system include “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h” and was related to conversion using AVX intel intrinsic. The error were of the type:
error: can’t convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
There is a stackoverflow post ( http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-... ) which describes a similar problem, which I haven't studied in depth, but they seem to suggest that it's a bug in gcc, and that setting --std=gnu++11 instead of --std=c++11 in CXXFLAGS will work around the problem.
Yes, it seems that this describes the problem we're having. GCC uses
__attribute__ to provide certain language extensions, e.g. for vectorization. These are not optional declarations -- these modify function definition and can't just be omitted.
And HDF5 does just that: it #defines __attribute__ to be empty (file H5api_adpt.h, near the beginning) if the file is included from C++. I have no idea why they would think this is legal, or why they would think this is even a good idea. We use __attribute__ in Cactus (after checking via autoconf whether it is supported) for a variety of optimizations and security checks.
I would try adding the line
#undef __attribute__
right after (below) any line that says
#include <hdf5.h>
to undo (part of) the damage that HDF5 does. We should also complain to the HDF5 authors.
So to summarise:
– HDF5 is undefining __attribute__, and this is a bug in hdf5. – In the stack overflow post, argp.h is undefining __attribute__, so this is a bug in glibc
Is that correct? My suggestion to try --std=gnu++11 in CXXFLAGS won't fix the problem in the HFD5 header; it would only affect the argp.h problem, which doesn't apply to us.
Digging a bit deeper, it seems that we have been bitten (again) by trying to track a moving target. The HDF5 MacPorts port was updated from 1.8.14 to 1.8.15 on 16-May-2015 ( https://trac.macports.org/log/trunk/dports/science/hdf5/Portfile), 2 days before the ET release, and after the release branches had been created and the final testing had been done. Note that this also happened with OpenMPI a few days before, introducing a critical regression which we were able to work around in time.
The responsible commit in HDF5 seems to be this one:
https://github.com/live-clones/hdf5/commit/b283f087e32fb99023650240ef8290a3f...
They were previously undefining __attribute__ only in H5private.h, which is included by hdf5 source files, but not from the public api used by user code, and this commit moves this definition into a public header file included by user code. Erik, do you want to contact the developers, since you understand this better than I do?
I think the most sensible workaround for us would be set HDF5_DIR = BUILD in osx-macports.cfg, since the current macports version is broken. MacPorts has a single tree, they don't split into stable and unstable branches, presumably due to lack of resources. The same is true of homebrew; presumably they will also update to 1.8.15 at some point, so maybe we should build HDF5 for homebrew as well. The Cactus-provided version in ExternalLibraries is 1.8.14.
-- Ian Hinder http://members.aei.mpg.de/ianhin
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi Ian,
I have downloaded a new version from scratch of Hilbert and have checked that I have installed all recommended macports, to wit:
ComerMacProRetina:~ comerduncan$ port installed pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 openmpi openssl The following ports are currently installed: fftw-3 @3.3.4_1 (active) fftw-3 @3.3.4_1+universal gcc49 @4.9.2_1 (active) gsl @1.16_3 (active) gsl @1.16_3+gcc46 hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.15_0+cxx+fortran+gfortran (active) hdf5 @1.8.15_0+cxx+gcc46 jpeg @9a_1 (active) openmpi @1.7.5_3 (active) openssl @1.0.1j_0 openssl @1.0.1j_0+universal openssl @1.0.2_0+universal openssl @1.0.2a_0 openssl @1.0.2a_0+universal (active) pkgconfig @0.28_0 (active) zlib @1.2.8_0 zlib @1.2.8_0+universal (active)
I then put in the new version of detect.pl that Frank recommended. When I build using the osx-macports config file, I still (today!) get a crash before the build completes. I am sort of at a loss about what to do further. I could completely nuke macports and reinstall all, which will take quite a while, but can do that if there is a good chance that it will help.
Do you have some recommendations of other things to try before the nuke option?
Thanks.
Comer
On Fri, May 22, 2015 at 12:34 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 16:10, Roberto De Pietri roberto.depietri@unipr.it wrote:
Hi Ian:
Thanks for the answer. I followed exactly your procedure and I was very surprised of having a failing compilation. Than I starting tracing back the problem.
- All the thorns except one were compiling correctly.
- The failing thorn was CarpetIOHDF5 and of the 5 source files present
only 3 failed
- The error was very strange because the only real problem was related to
a system include “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h” and was related to conversion using AVX intel intrinsic. The error were of the type:
error: can’t convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
There is a stackoverflow post ( http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-... ) which describes a similar problem, which I haven't studied in depth, but they seem to suggest that it's a bug in gcc, and that setting --std=gnu++11 instead of --std=c++11 in CXXFLAGS will work around the problem. We currently have
CXXFLAGS = -g -std=c++14
so I'm guessing that changing this to
CXXFLAGS = -g -std=gnu++14
might have the same effect.
What I don't understand is why we didn't pick this up in testing. I successfully compiled the whole ET using exactly that set of MacPorts packages and the optionlist before the release, and the gcc49 macports package hasn't been updated since 4 weeks ago.
When you say you followed exactly my procedure, do you mean that you get the above compilation problem even when you have only the ports listed in the optionlist installed, and have not installed anything else, such as gcc5 or the python packages?
-- Ian Hinder http://members.aei.mpg.de/ianhin
Dear Cormer:
till the problem is sorted out you can just have a try modifying just 3 files in CarpetIOHDF5/src namely:
======================================================= diff --git a/CarpetIOHDF5/src/GetAllActive.cc http://getallactive.cc/ b/CarpetIOHDF5/src/GetAllActive.cc http://getallactive.cc/ index bb92f4a..bb5d2da 100644 --- a/CarpetIOHDF5/src/GetAllActive.cc http://getallactive.cc/ +++ b/CarpetIOHDF5/src/GetAllActive.cc http://getallactive.cc/ @@ -8,8 +8,14 @@ @@*/
#include <cassert> - +#include <cstdlib> +#include <cstring> +#include <list> +#include <sstream> +#include <string> #include <vector> +#include <map> +#include <algorithm>
#include "cctk.h"
diff --git a/CarpetIOHDF5/src/Output.cc http://output.cc/ b/CarpetIOHDF5/src/Output.cc http://output.cc/ index ecef6b8..da82b87 100644 --- a/CarpetIOHDF5/src/Output.cc http://output.cc/ +++ b/CarpetIOHDF5/src/Output.cc http://output.cc/ @@ -1,7 +1,12 @@ #include <cassert> #include <cstdlib> #include <cstring> +#include <list> #include <sstream> +#include <string> +#include <vector> +#include <map> +#include <algorithm>
#include "cctk.h" #include "cctk_Arguments.h" diff --git a/CarpetIOHDF5/src/OutputSlice.cc http://outputslice.cc/ b/CarpetIOHDF5/src/OutputSlice.cc http://outputslice.cc/ index 43763fb..82a4db6 100644 --- a/CarpetIOHDF5/src/OutputSlice.cc http://outputslice.cc/ +++ b/CarpetIOHDF5/src/OutputSlice.cc http://outputslice.cc/ @@ -1,9 +1,12 @@ #include <cassert> -#include <cctype> -#include <climits> -#include <cmath> #include <cstdlib> #include <cstring> +#include <list> +#include <sstream> +#include <string> +#include <vector> +#include <map> +#include <algorithm>
#include <map> #include <string>
========================================================
Just these changes at the begining of the three files.
I am sorry not having more time for detail but here in Italy is already 7:00pn on Friday .
Roberto
Il giorno 22/mag/2015, alle ore 18:41, Comer Duncan comer.duncan@gmail.com ha scritto:
Hi Ian,
I have downloaded a new version from scratch of Hilbert and have checked that I have installed all recommended macports, to wit:
ComerMacProRetina:~ comerduncan$ port installed pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 openmpi openssl The following ports are currently installed: fftw-3 @3.3.4_1 (active) fftw-3 @3.3.4_1+universal gcc49 @4.9.2_1 (active) gsl @1.16_3 (active) gsl @1.16_3+gcc46 hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.15_0+cxx+fortran+gfortran (active) hdf5 @1.8.15_0+cxx+gcc46 jpeg @9a_1 (active) openmpi @1.7.5_3 (active) openssl @1.0.1j_0 openssl @1.0.1j_0+universal openssl @1.0.2_0+universal openssl @1.0.2a_0 openssl @1.0.2a_0+universal (active) pkgconfig @0.28_0 (active) zlib @1.2.8_0 zlib @1.2.8_0+universal (active)
I then put in the new version of detect.pl http://detect.pl/ that Frank recommended. When I build using the osx-macports config file, I still (today!) get a crash before the build completes. I am sort of at a loss about what to do further. I could completely nuke macports and reinstall all, which will take quite a while, but can do that if there is a good chance that it will help.
Do you have some recommendations of other things to try before the nuke option?
Thanks.
Comer
On Fri, May 22, 2015 at 12:34 PM, Ian Hinder <ian.hinder@aei.mpg.de mailto:ian.hinder@aei.mpg.de> wrote:
On 22 May 2015, at 16:10, Roberto De Pietri <roberto.depietri@unipr.it mailto:roberto.depietri@unipr.it> wrote:
Hi Ian:
Thanks for the answer. I followed exactly your procedure and I was very surprised of having a failing compilation. Than I starting tracing back the problem.
- All the thorns except one were compiling correctly.
- The failing thorn was CarpetIOHDF5 and of the 5 source files present only 3 failed
- The error was very strange because the only real problem was related to
a system include “/opt/local/lib/gcc49/gcc/x86_64-apple-darwin14/4.9.2/include/mmintrin.h” and was related to conversion using AVX intel intrinsic. The error were of the type:
error: can’t convert between vector values of different size return (__m64) __builtin_ia32_vec_init_v2si (__i, 0);
There is a stackoverflow post (http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-... http://stackoverflow.com/questions/19043109/gcc-4-8-1-combining-c-code-with-c11-code ) which describes a similar problem, which I haven't studied in depth, but they seem to suggest that it's a bug in gcc, and that setting --std=gnu++11 instead of --std=c++11 in CXXFLAGS will work around the problem. We currently have
CXXFLAGS = -g -std=c++14
so I'm guessing that changing this to
CXXFLAGS = -g -std=gnu++14
might have the same effect.
What I don't understand is why we didn't pick this up in testing. I successfully compiled the whole ET using exactly that set of MacPorts packages and the optionlist before the release, and the gcc49 macports package hasn't been updated since 4 weeks ago.
When you say you followed exactly my procedure, do you mean that you get the above compilation problem even when you have only the ports listed in the optionlist installed, and have not installed anything else, such as gcc5 or the python packages?
-- Ian Hinder http://members.aei.mpg.de/ianhin http://members.aei.mpg.de/ianhin
------------------------------------------------------------------ Roberto De Pietri e-mail:roberto.depietri@fis.unipr.it mailto:roberto.depietri@fis.unipr.it Dipartimento di Fisica http://www.fis.unipr.it/~roberto.depietri http://www.fis.unipr.it/~roberto.depietri Universita' di Parma tel: +39 (0521) 905280 Via G.P.Usberti 7/A fax: +39 (0521) 905223 I-43100 PARMA --- ITALY
On 22 May 2015, at 18:41, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
I have downloaded a new version from scratch of Hilbert and have checked that I have installed all recommended macports, to wit:
ComerMacProRetina:~ comerduncan$ port installed pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 openmpi openssl The following ports are currently installed: fftw-3 @3.3.4_1 (active) fftw-3 @3.3.4_1+universal gcc49 @4.9.2_1 (active) gsl @1.16_3 (active) gsl @1.16_3+gcc46 hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.15_0+cxx+fortran+gfortran (active) hdf5 @1.8.15_0+cxx+gcc46 jpeg @9a_1 (active) openmpi @1.7.5_3 (active) openssl @1.0.1j_0 openssl @1.0.1j_0+universal openssl @1.0.2_0+universal openssl @1.0.2a_0 openssl @1.0.2a_0+universal (active) pkgconfig @0.28_0 (active) zlib @1.2.8_0 zlib @1.2.8_0+universal (active)
I then put in the new version of detect.pl that Frank recommended. When I build using the osx-macports config file, I still (today!) get a crash before the build completes. I am sort of at a loss about what to do further. I could completely nuke macports and reinstall all, which will take quite a while, but can do that if there is a good chance that it will help.
Hi Comer,
Is the compilation error the same as before, or is it now different? I am assuming that you are doing a full recompile each time, by deleting the configuration from configs. If you are getting the same error as Roberto, you could try his suggested fix (editing the includes) or mine (changing the CXXFLAGS) from the other emails.
Do you have some recommendations of other things to try before the nuke option?
When I was testing, installing the required packages from MacPorts on a completely empty macports tree took about half an hour, I think, comparable to the ET build itself.
Hi Ian,
I have done a build first commenting out CARPETIOHDF5 in the thorns file. This time it builds to completion.
I have tried running the static_tov test. But since CarpetIOHDF5 thorn was disabled in the build, the test aborts. Is there a test which does not need CarpetIOHDF5, i.e. uses a different IO?
Comer
On Fri, May 22, 2015 at 1:57 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 18:41, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
I have downloaded a new version from scratch of Hilbert and have checked that I have installed all recommended macports, to wit:
ComerMacProRetina:~ comerduncan$ port installed pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 openmpi openssl The following ports are currently installed: fftw-3 @3.3.4_1 (active) fftw-3 @3.3.4_1+universal gcc49 @4.9.2_1 (active) gsl @1.16_3 (active) gsl @1.16_3+gcc46 hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.15_0+cxx+fortran+gfortran (active) hdf5 @1.8.15_0+cxx+gcc46 jpeg @9a_1 (active) openmpi @1.7.5_3 (active) openssl @1.0.1j_0 openssl @1.0.1j_0+universal openssl @1.0.2_0+universal openssl @1.0.2a_0 openssl @1.0.2a_0+universal (active) pkgconfig @0.28_0 (active) zlib @1.2.8_0 zlib @1.2.8_0+universal (active)
I then put in the new version of detect.pl that Frank recommended. When I build using the osx-macports config file, I still (today!) get a crash before the build completes. I am sort of at a loss about what to do further. I could completely nuke macports and reinstall all, which will take quite a while, but can do that if there is a good chance that it will help.
Hi Comer,
Is the compilation error the same as before, or is it now different? I am assuming that you are doing a full recompile each time, by deleting the configuration from configs. If you are getting the same error as Roberto, you could try his suggested fix (editing the includes) or mine (changing the CXXFLAGS) from the other emails.
Do you have some recommendations of other things to try before the nuke option?
When I was testing, installing the required packages from MacPorts on a completely empty macports tree took about half an hour, I think, comparable to the ET build itself.
-- Ian Hinder http://members.aei.mpg.de/ianhin
On 22 May 2015, at 21:16, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
I have done a build first commenting out CARPETIOHDF5 in the thorns file. This time it builds to completion.
I have tried running the static_tov test. But since CarpetIOHDF5 thorn was disabled in the build, the test aborts. Is there a test which does not need CarpetIOHDF5, i.e. uses a different IO?
Hi Comer,
Looking at the parameter file, I don't see why it needs the CarpetIOHDF5 thorn; it doesn't seem to do anything with it! So you should be able to remove CarpetIOHDF5 from the ActiveThorns line at the top of static_tov.par. i.e. replace
ActiveThorns = "CarpetIOASCII CarpetIOScalar CarpetIOHDF5 CarpetIOBasic"
with
ActiveThorns = "CarpetIOASCII CarpetIOScalar CarpetIOBasic"
I just tested this, and it works without that thorn.
Can you let me know whether the error you got when you include CarpetIOHDF5 in the thornlist is that same as before, or if it's the one that Roberto got?
By the way, which tutorial or example are you following?
Comer
On Fri, May 22, 2015 at 1:57 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 18:41, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
I have downloaded a new version from scratch of Hilbert and have checked that I have installed all recommended macports, to wit:
ComerMacProRetina:~ comerduncan$ port installed pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 openmpi openssl The following ports are currently installed: fftw-3 @3.3.4_1 (active) fftw-3 @3.3.4_1+universal gcc49 @4.9.2_1 (active) gsl @1.16_3 (active) gsl @1.16_3+gcc46 hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.15_0+cxx+fortran+gfortran (active) hdf5 @1.8.15_0+cxx+gcc46 jpeg @9a_1 (active) openmpi @1.7.5_3 (active) openssl @1.0.1j_0 openssl @1.0.1j_0+universal openssl @1.0.2_0+universal openssl @1.0.2a_0 openssl @1.0.2a_0+universal (active) pkgconfig @0.28_0 (active) zlib @1.2.8_0 zlib @1.2.8_0+universal (active)
I then put in the new version of detect.pl that Frank recommended. When I build using the osx-macports config file, I still (today!) get a crash before the build completes. I am sort of at a loss about what to do further. I could completely nuke macports and reinstall all, which will take quite a while, but can do that if there is a good chance that it will help.
Hi Comer,
Is the compilation error the same as before, or is it now different? I am assuming that you are doing a full recompile each time, by deleting the configuration from configs. If you are getting the same error as Roberto, you could try his suggested fix (editing the includes) or mine (changing the CXXFLAGS) from the other emails.
Do you have some recommendations of other things to try before the nuke option?
When I was testing, installing the required packages from MacPorts on a completely empty macports tree took about half an hour, I think, comparable to the ET build itself.
-- Ian Hinder http://members.aei.mpg.de/ianhin
Hi Ian,
Sorry...you should be out having a beer or something rather than this on a Friday! Thanks for the reply!
I don't think my errors in builds were the same as Roberto's. This is a muddy debugging problem, as Roberto and I seem not to have the same set of macports--he has some I don't and both of us have the required list. I am also using the new detect.pl file and until the last build I had CarptetIOHDF5 mentioned in einsteinthornlist.th...so I am not sure we can get a side by side comparison....sort of disappointing but probably nearer reality of various users inequivalent installations on their machines.
I will give your suggestion of simply removing mention of CarpetIOHDF5 from active thorns and see what happens...
Comer
On Fri, May 22, 2015 at 3:36 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 21:16, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
I have done a build first commenting out CARPETIOHDF5 in the thorns file. This time it builds to completion.
I have tried running the static_tov test. But since CarpetIOHDF5 thorn was disabled in the build, the test aborts. Is there a test which does not need CarpetIOHDF5, i.e. uses a different IO?
Hi Comer,
Looking at the parameter file, I don't see why it needs the CarpetIOHDF5 thorn; it doesn't seem to do anything with it! So you should be able to remove CarpetIOHDF5 from the ActiveThorns line at the top of static_tov.par. i.e. replace
ActiveThorns = "CarpetIOASCII CarpetIOScalar CarpetIOHDF5 CarpetIOBasic"
with
ActiveThorns = "CarpetIOASCII CarpetIOScalar CarpetIOBasic"
I just tested this, and it works without that thorn.
Can you let me know whether the error you got when you include CarpetIOHDF5 in the thornlist is that same as before, or if it's the one that Roberto got?
By the way, which tutorial or example are you following?
Comer
On Fri, May 22, 2015 at 1:57 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 18:41, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
I have downloaded a new version from scratch of Hilbert and have checked that I have installed all recommended macports, to wit:
ComerMacProRetina:~ comerduncan$ port installed pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 openmpi openssl The following ports are currently installed: fftw-3 @3.3.4_1 (active) fftw-3 @3.3.4_1+universal gcc49 @4.9.2_1 (active) gsl @1.16_3 (active) gsl @1.16_3+gcc46 hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.15_0+cxx+fortran+gfortran (active) hdf5 @1.8.15_0+cxx+gcc46 jpeg @9a_1 (active) openmpi @1.7.5_3 (active) openssl @1.0.1j_0 openssl @1.0.1j_0+universal openssl @1.0.2_0+universal openssl @1.0.2a_0 openssl @1.0.2a_0+universal (active) pkgconfig @0.28_0 (active) zlib @1.2.8_0 zlib @1.2.8_0+universal (active)
I then put in the new version of detect.pl that Frank recommended. When I build using the osx-macports config file, I still (today!) get a crash before the build completes. I am sort of at a loss about what to do further. I could completely nuke macports and reinstall all, which will take quite a while, but can do that if there is a good chance that it will help.
Hi Comer,
Is the compilation error the same as before, or is it now different? I am assuming that you are doing a full recompile each time, by deleting the configuration from configs. If you are getting the same error as Roberto, you could try his suggested fix (editing the includes) or mine (changing the CXXFLAGS) from the other emails.
Do you have some recommendations of other things to try before the nuke option?
When I was testing, installing the required packages from MacPorts on a completely empty macports tree took about half an hour, I think, comparable to the ET build itself.
-- Ian Hinder http://members.aei.mpg.de/ianhin
-- Ian Hinder http://members.aei.mpg.de/ianhin
Hi Ian,
You asked: "By the way, which tutorial or example are you following?"
I forgot to answer this. I am using the one at https://docs.einsteintoolkit.org/et-docs/Tutorial_for_New_Users.
Also yesterday I ran the static_tov test using all four cores and the test ran a little faster than it ran without explicit mention of the number of cores per node. Here is the explicity usage:
./simfactory/bin/sim submit static_tov --parfile=par/static_tov.par --procs=1 --ppn-used=4 --walltime=16:0:0
DId I use the options appropriately?
Thanks again for your help.
Comer
On Fri, May 22, 2015 at 3:36 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 21:16, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
I have done a build first commenting out CARPETIOHDF5 in the thorns file. This time it builds to completion.
I have tried running the static_tov test. But since CarpetIOHDF5 thorn was disabled in the build, the test aborts. Is there a test which does not need CarpetIOHDF5, i.e. uses a different IO?
Hi Comer,
Looking at the parameter file, I don't see why it needs the CarpetIOHDF5 thorn; it doesn't seem to do anything with it! So you should be able to remove CarpetIOHDF5 from the ActiveThorns line at the top of static_tov.par. i.e. replace
ActiveThorns = "CarpetIOASCII CarpetIOScalar CarpetIOHDF5 CarpetIOBasic"
with
ActiveThorns = "CarpetIOASCII CarpetIOScalar CarpetIOBasic"
I just tested this, and it works without that thorn.
Can you let me know whether the error you got when you include CarpetIOHDF5 in the thornlist is that same as before, or if it's the one that Roberto got?
By the way, which tutorial or example are you following?
Comer
On Fri, May 22, 2015 at 1:57 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 22 May 2015, at 18:41, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
I have downloaded a new version from scratch of Hilbert and have checked that I have installed all recommended macports, to wit:
ComerMacProRetina:~ comerduncan$ port installed pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 openmpi openssl The following ports are currently installed: fftw-3 @3.3.4_1 (active) fftw-3 @3.3.4_1+universal gcc49 @4.9.2_1 (active) gsl @1.16_3 (active) gsl @1.16_3+gcc46 hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.15_0+cxx+fortran+gfortran (active) hdf5 @1.8.15_0+cxx+gcc46 jpeg @9a_1 (active) openmpi @1.7.5_3 (active) openssl @1.0.1j_0 openssl @1.0.1j_0+universal openssl @1.0.2_0+universal openssl @1.0.2a_0 openssl @1.0.2a_0+universal (active) pkgconfig @0.28_0 (active) zlib @1.2.8_0 zlib @1.2.8_0+universal (active)
I then put in the new version of detect.pl that Frank recommended. When I build using the osx-macports config file, I still (today!) get a crash before the build completes. I am sort of at a loss about what to do further. I could completely nuke macports and reinstall all, which will take quite a while, but can do that if there is a good chance that it will help.
Hi Comer,
Is the compilation error the same as before, or is it now different? I am assuming that you are doing a full recompile each time, by deleting the configuration from configs. If you are getting the same error as Roberto, you could try his suggested fix (editing the includes) or mine (changing the CXXFLAGS) from the other emails.
Do you have some recommendations of other things to try before the nuke option?
When I was testing, installing the required packages from MacPorts on a completely empty macports tree took about half an hour, I think, comparable to the ET build itself.
-- Ian Hinder http://members.aei.mpg.de/ianhin
-- Ian Hinder http://members.aei.mpg.de/ianhin
On 26 May 2015, at 16:03, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
You asked: "By the way, which tutorial or example are you following?"
I forgot to answer this. I am using the one at https://docs.einsteintoolkit.org/et-docs/Tutorial_for_New_Users.
Also yesterday I ran the static_tov test using all four cores and the test ran a little faster than it ran without explicit mention of the number of cores per node. Here is the explicity usage:
./simfactory/bin/sim submit static_tov --parfile=par/static_tov.par --procs=1 --ppn-used=4 --walltime=16:0:0
DId I use the options appropriately?
Thanks again for your help.
No :) The terminology for cores etc is very confusing. --procs indicates the number of threads you want to run in TOTAL, which is usually equal to the number of cores you want to use. So if you want to run on all four cores, you should use --procs 4. You may have to also use --ppn-used, as you have, if your machine definition doesn't match your hardware; I'm not sure how intelligent the setup procedure is. Assuming you have a quad-core single-processor machine, you probably want to have
ppn = 4 # cores per node max-num-threads = 4 # maximum number of threads per process num-threads = 1 # default number of threads per process nodes = 1
in your machine.ini file. This should allow you to run on either 1, 2, 3 or 4 processes, in each case using only a single thread, using just --procs N without needing to specify ppn-used. If you want to use OpenMP (multiple threads per process), you will still keep --procs as the total number of cores/threads to use, but specify --num-threads as the number of threads per process. So for example, --procs 4 --num-threads 2 would give you 4 cores/threads, divided between 2 processes each with 2 threads.
If you want to allow "oversubscription", i.e. pretend that you have more cores than you really do, which is needed in some cases if you want to force a larger number of MPI processes, you can set nodes = 10 or something.
This is explained carefully at http://simfactory.org/info/documentation/userguide/processterminology.html.
Dear Comer:
I would like to confirm you that Ian and Eric were able to correctly find out the problem that originated the build problem on build using macports * The HDF5 MacPorts port was updated from 1.8.14 to 1.8.15 on 16-May-2015 (https://trac.macports.org/log/trunk/dports/science/hdf5/Portfile), 2 days before the ET release * HDF5 is undefining __attribute__, and this is creating site effect (caused by including hdf5.h) that have standard c++ include to fail. This is true for gcc4.8 and gcc5.1 * A simple solution is to change the order of includes in the include file: arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh. you can replace this include with the one attached to the present mail. * to have a fast start you may also copy the attached file: osx-macports.run in simfactory/mdb/runscript. * then set your local machine with the command
simfactory/bin/sim setup
* edit the local machine file you created (using the previous command) in simfactory/mdb/machine to have:
*** ASSUMING MACPORT IS INSTALLED (subversion is needed cause the version that comes with XCOde *** will not work [new XCODE 6.3.2 and MacPorts 2.3.3]
sudo port install subversion sudo port install pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 +fortran +gfortran openmpi openssl
### [FROM a MAIN DIRECTORY for the Cactus tree]
curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/ET_2015_05/GetComponents chmod a+x GetComponents ./GetComponents --parallel https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2015_05/einsteintoolki...
### [the enter in the cactus directory]
cd Cactus
cp [where_you_save_it]/CarpetIOHDF5.hh arrangements/Carpet/CarpetIOHDF5/src/ cp [where_you_save_it]/osx-macports.run simfactory/mdb/runscript simfactory/bin/sim setup
### [DO the local editing. In my case was the file named] ### the following line should be present ### ### optionlist = osx-macports.cfg ### runscript = osx-macports.run ### ppn = 4 ### max-num-threads = 4 ### num-threads = 1 ### nodes = 1 ### ### NOT: my machine is “iMac (27-inch, Late 2009)” ### OS X Yosemite 10.10.3 ### ### Processor Name: Intel Core i5 ### Processor Speed: 2,66 GHz ### Number of Processors: 1 ### Total Number of Cores: 4 ### L2 Cache (per Core): 256 KB ### L3 Cache: 8 MB ### Memory: 8 GB
simfactory/bin/sim build --thornlist thornlists/einsteintoolkit.th simfactory/bin/sim create-run static_tov --parfile=par/static_tov.par --proc=4 --num-threads=2
### Now the test TOV simulations should be running code is running on two process using two cores each.
## sudo port install python27 ## sudo port select —set python python27 ## sudo port install py-numpy py-scipy ## sudo port install py-matplotlib ## sudo port install py-h5py ## sudo port install py-ipython ## sudo port select —set ipython ipython27 ## ## ## TO SEE THE RESULTS:
ipython —-pylab
In [..]: FILE='/Users/depietri/simulations/static_tov/output-0000/static_tov/hydrobase-rho.maximum.asc' In [..]: d=loadtxt(FILE) In [..]: plot(d[:,1],d[:,2]*1e3,'k-') In [..]: ylim(1.25,1.30) In [..]: xlabel(r’time [CU c=1, G=1, $M_\odot$=1]') In [..]: ylabel(r'max($\rho \cdot 10^3$) [CU c=1, G=1, $M_\odot$=1]') In [..]:
------------------------------------------------------------------ Roberto De Pietri e-mail:roberto.depietri@fis.unipr.it Dipartimento di Fisica http://www.fis.unipr.it/~roberto.depietri Universita' di Parma tel: +39 (0521) 905280 Via G.P.Usberti 7/A fax: +39 (0521) 905223 I-43100 PARMA --- ITALY
On 27 May 2015, at 16:30, Roberto De Pietri roberto.depietri@unipr.it wrote:
Dear Comer:
I would like to confirm you that Ian and Eric were able to correctly find out the problem that originated the build problem on build using macports
- The HDF5 MacPorts port was updated from 1.8.14 to 1.8.15 on 16-May-2015
(https://trac.macports.org/log/trunk/dports/science/hdf5/Portfile), 2 days before the ET release
- HDF5 is undefining __attribute__, and this is creating site effect (caused by including hdf5.h)
that have standard c++ include to fail. This is true for gcc4.8 and gcc5.1
- A simple solution is to change the order of includes in the include file:
arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh. you can replace this include with the one attached to the present mail.
This seems like a viable workaround until the problem is fixed in HDF5, so I propose that it be implemented in CarpetIOHDF5 and backported to the release branch.
- to have a fast start you may also copy the attached file: osx-macports.run in simfactory/mdb/runscript.
- then set your local machine with the command
simfactory/bin/sim setup
- edit the local machine file you created (using the previous command) in simfactory/mdb/machine
to have:
*** ASSUMING MACPORT IS INSTALLED (subversion is needed cause the version that comes with XCOde *** will not work [new XCODE 6.3.2 and MacPorts 2.3.3]
sudo port install subversion sudo port install pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 +fortran +gfortran openmpi openssl
### [FROM a MAIN DIRECTORY for the Cactus tree]
curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/ET_2015_05/GetComponents chmod a+x GetComponents ./GetComponents --parallel https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2015_05/einsteintoolki...
### [the enter in the cactus directory]
cd Cactus
cp [where_you_save_it]/CarpetIOHDF5.hh arrangements/Carpet/CarpetIOHDF5/src/ cp [where_you_save_it]/osx-macports.run simfactory/mdb/runscript simfactory/bin/sim setup
### [DO the local editing. In my case was the file named] ### the following line should be present ### ### optionlist = osx-macports.cfg ### runscript = osx-macports.run ### ppn = 4 ### max-num-threads = 4 ### num-threads = 1 ### nodes = 1 ### ### NOT: my machine is “iMac (27-inch, Late 2009)” ### OS X Yosemite 10.10.3 ### ### Processor Name: Intel Core i5 ### Processor Speed: 2,66 GHz ### Number of Processors: 1 ### Total Number of Cores: 4 ### L2 Cache (per Core): 256 KB ### L3 Cache: 8 MB ### Memory: 8 GB
simfactory/bin/sim build --thornlist thornlists/einsteintoolkit.th simfactory/bin/sim create-run static_tov --parfile=par/static_tov.par --proc=4 --num-threads=2
### Now the test TOV simulations should be running code is running on two process using two cores each.
## sudo port install python27 ## sudo port select —set python python27 ## sudo port install py-numpy py-scipy ## sudo port install py-matplotlib ## sudo port install py-h5py ## sudo port install py-ipython ## sudo port select —set ipython ipython27 ## ## ## TO SEE THE RESULTS:
ipython —-pylab
In [..]: FILE='/Users/depietri/simulations/static_tov/output-0000/static_tov/hydrobase-rho.maximum.asc' In [..]: d=loadtxt(FILE) In [..]: plot(d[:,1],d[:,2]*1e3,'k-') In [..]: ylim(1.25,1.30) In [..]: xlabel(r’time [CU c=1, G=1, $M_\odot$=1]') In [..]: ylabel(r'max($\rho \cdot 10^3$) [CU c=1, G=1, $M_\odot$=1]') In [..]:
<CarpetIOHDF5.hh><osx-macports.run>
Roberto De Pietri e-mail:roberto.depietri@fis.unipr.it Dipartimento di Fisica http://www.fis.unipr.it/~roberto.depietri Universita' di Parma tel: +39 (0521) 905280 Via G.P.Usberti 7/A fax: +39 (0521) 905223 I-43100 PARMA --- ITALY
On Wed, May 27, 2015 at 04:48:19PM +0200, Ian Hinder wrote:
This seems like a viable workaround until the problem is fixed in HDF5, so I propose that it be implemented in CarpetIOHDF5 and backported to the release branch.
I agree. For the record: was the problem reported to the HDF5 group?
Frank
On 27 May 2015, at 17:20, Frank Loeffler knarf@cct.lsu.edu wrote:
On Wed, May 27, 2015 at 04:48:19PM +0200, Ian Hinder wrote:
This seems like a viable workaround until the problem is fixed in HDF5, so I propose that it be implemented in CarpetIOHDF5 and backported to the release branch.
I agree. For the record: was the problem reported to the HDF5 group?
Yes, and they have asked for a test case. I don't have time to produce one at the moment, and it really shouldn't be necessary. It is clearly wrong to undefine __attribute__ in a public header file.
Instead of changing the order, can we add "#undef __attribute__" after #inluding <hdf5.h>, with a respective comment? This would undo more of the damage.
-erik
On Wed, May 27, 2015 at 10:48 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 27 May 2015, at 16:30, Roberto De Pietri roberto.depietri@unipr.it wrote:
Dear Comer:
I would like to confirm you that Ian and Eric were able to correctly find out the problem that originated the build problem on build using macports
- The HDF5 MacPorts port was updated from 1.8.14 to 1.8.15 on 16-May-2015
(https://trac.macports.org/log/trunk/dports/science/hdf5/Portfile), 2 days before the ET release
- HDF5 is undefining __attribute__, and this is creating site effect
(caused by including hdf5.h) that have standard c++ include to fail. This is true for gcc4.8 and gcc5.1
- A simple solution is to change the order of includes in the include
file: arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh. you can replace this include with the one attached to the present mail.
This seems like a viable workaround until the problem is fixed in HDF5, so I propose that it be implemented in CarpetIOHDF5 and backported to the release branch.
- to have a fast start you may also copy the attached file:
osx-macports.run in simfactory/mdb/runscript.
- then set your local machine with the command
simfactory/bin/sim setup
- edit the local machine file you created (using the previous command) in
simfactory/mdb/machine to have:
*** ASSUMING MACPORT IS INSTALLED (subversion is needed cause the version that comes with XCOde *** will not work [new XCODE 6.3.2 and MacPorts 2.3.3]
sudo port install subversion sudo port install pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 +fortran +gfortran openmpi openssl
### [FROM a MAIN DIRECTORY for the Cactus tree]
curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/ET_2015_05/GetComponents chmod a+x GetComponents ./GetComponents --parallel https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2015_05/einsteintoolki...
### [the enter in the cactus directory]
cd Cactus
cp [where_you_save_it]/CarpetIOHDF5.hh arrangements/Carpet/CarpetIOHDF5/src/ cp [where_you_save_it]/osx-macports.run simfactory/mdb/runscript simfactory/bin/sim setup
### [DO the local editing. In my case was the file named] ### the following line should be present ### ### optionlist = osx-macports.cfg ### runscript = osx-macports.run ### ppn = 4 ### max-num-threads = 4 ### num-threads = 1 ### nodes = 1 ### ### NOT: my machine is “iMac (27-inch, Late 2009)” ### OS X Yosemite 10.10.3 ### ### Processor Name: Intel Core i5 ### Processor Speed: 2,66 GHz ### Number of Processors: 1 ### Total Number of Cores: 4 ### L2 Cache (per Core): 256 KB ### L3 Cache: 8 MB ### Memory: 8 GB
simfactory/bin/sim build --thornlist thornlists/einsteintoolkit.th simfactory/bin/sim create-run static_tov --parfile=par/static_tov.par --proc=4 --num-threads=2
### Now the test TOV simulations should be running code is running on two process using two cores each.
## sudo port install python27 ## sudo port select —set python python27 ## sudo port install py-numpy py-scipy ## sudo port install py-matplotlib ## sudo port install py-h5py ## sudo port install py-ipython ## sudo port select —set ipython ipython27 ## ## ## TO SEE THE RESULTS:
ipython —-pylab
In [..]: FILE='/Users/depietri/simulations/static_tov/output-0000/static_tov/hydrobase-rho.maximum.asc' In [..]: d=loadtxt(FILE) In [..]: plot(d[:,1],d[:,2]*1e3,'k-') In [..]: ylim(1.25,1.30) In [..]: xlabel(r’time [CU c=1, G=1, $M_\odot$=1]') In [..]: ylabel(r'max($\rho \cdot 10^3$) [CU c=1, G=1, $M_\odot$=1]') In [..]:
<CarpetIOHDF5.hh><osx-macports.run>
Roberto De Pietri e-mail:roberto.depietri@fis.unipr.it Dipartimento di Fisica http://www.fis.unipr.it/~roberto.depietri Universita' di Parma tel: +39 (0521) 905280 Via G.P.Usberti 7/A fax: +39 (0521) 905223 I-43100 PARMA --- ITALY
-- Ian Hinder http://members.aei.mpg.de/ianhin
On 28 May 2015, at 01:03, Erik Schnetter schnetter@cct.lsu.edu wrote:
Instead of changing the order, can we add "#undef __attribute__" after #inluding <hdf5.h>, with a respective comment? This would undo more of the damage.
So the definition of __attribute__ in hdf5 is overriding the built-in symbol with a macro, which allows us to then undefine the macro afterwards, which allows the built-in symbol to be visible again? I was confused because I was thinking that undefining __attribute__ was the cause of the original problem.
-erik
On Wed, May 27, 2015 at 10:48 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 27 May 2015, at 16:30, Roberto De Pietri roberto.depietri@unipr.it wrote:
Dear Comer:
I would like to confirm you that Ian and Eric were able to correctly find out the problem that originated the build problem on build using macports
- The HDF5 MacPorts port was updated from 1.8.14 to 1.8.15 on 16-May-2015
(https://trac.macports.org/log/trunk/dports/science/hdf5/Portfile), 2 days before the ET release
- HDF5 is undefining __attribute__, and this is creating site effect (caused by including hdf5.h)
that have standard c++ include to fail. This is true for gcc4.8 and gcc5.1
- A simple solution is to change the order of includes in the include file:
arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh. you can replace this include with the one attached to the present mail.
This seems like a viable workaround until the problem is fixed in HDF5, so I propose that it be implemented in CarpetIOHDF5 and backported to the release branch.
- to have a fast start you may also copy the attached file: osx-macports.run in simfactory/mdb/runscript.
- then set your local machine with the command
simfactory/bin/sim setup
- edit the local machine file you created (using the previous command) in simfactory/mdb/machine
to have:
*** ASSUMING MACPORT IS INSTALLED (subversion is needed cause the version that comes with XCOde *** will not work [new XCODE 6.3.2 and MacPorts 2.3.3]
sudo port install subversion sudo port install pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 +fortran +gfortran openmpi openssl
### [FROM a MAIN DIRECTORY for the Cactus tree]
curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/ET_2015_05/GetComponents chmod a+x GetComponents ./GetComponents --parallel https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2015_05/einsteintoolki...
### [the enter in the cactus directory]
cd Cactus
cp [where_you_save_it]/CarpetIOHDF5.hh arrangements/Carpet/CarpetIOHDF5/src/ cp [where_you_save_it]/osx-macports.run simfactory/mdb/runscript simfactory/bin/sim setup
### [DO the local editing. In my case was the file named] ### the following line should be present ### ### optionlist = osx-macports.cfg ### runscript = osx-macports.run ### ppn = 4 ### max-num-threads = 4 ### num-threads = 1 ### nodes = 1 ### ### NOT: my machine is “iMac (27-inch, Late 2009)” ### OS X Yosemite 10.10.3 ### ### Processor Name: Intel Core i5 ### Processor Speed: 2,66 GHz ### Number of Processors: 1 ### Total Number of Cores: 4 ### L2 Cache (per Core): 256 KB ### L3 Cache: 8 MB ### Memory: 8 GB
simfactory/bin/sim build --thornlist thornlists/einsteintoolkit.th simfactory/bin/sim create-run static_tov --parfile=par/static_tov.par --proc=4 --num-threads=2
### Now the test TOV simulations should be running code is running on two process using two cores each.
## sudo port install python27 ## sudo port select —set python python27 ## sudo port install py-numpy py-scipy ## sudo port install py-matplotlib ## sudo port install py-h5py ## sudo port install py-ipython ## sudo port select —set ipython ipython27 ## ## ## TO SEE THE RESULTS:
ipython —-pylab
In [..]: FILE='/Users/depietri/simulations/static_tov/output-0000/static_tov/hydrobase-rho.maximum.asc' In [..]: d=loadtxt(FILE) In [..]: plot(d[:,1],d[:,2]*1e3,'k-') In [..]: ylim(1.25,1.30) In [..]: xlabel(r’time [CU c=1, G=1, $M_\odot$=1]') In [..]: ylabel(r'max($\rho \cdot 10^3$) [CU c=1, G=1, $M_\odot$=1]') In [..]:
<CarpetIOHDF5.hh><osx-macports.run>
Roberto De Pietri e-mail:roberto.depietri@fis.unipr.it Dipartimento di Fisica http://www.fis.unipr.it/~roberto.depietri Universita' di Parma tel: +39 (0521) 905280 Via G.P.Usberti 7/A fax: +39 (0521) 905223 I-43100 PARMA --- ITALY
-- Ian Hinder http://members.aei.mpg.de/ianhin
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
Yes.
Originally, __attribute__ is a built-in keyword for the compiler. It is not a macro, as others suggested earlier. If you #define it to be empty, then the compiler will never see the keyword, as the preprocessor deletes it. So using #undef exactly undoes the action of the HDF5 header file, making the original keyword again visible to the compiler.
-erik
On Thu, May 28, 2015 at 4:36 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 28 May 2015, at 01:03, Erik Schnetter schnetter@cct.lsu.edu wrote:
Instead of changing the order, can we add "#undef __attribute__" after #inluding <hdf5.h>, with a respective comment? This would undo more of the damage.
So the definition of __attribute__ in hdf5 is overriding the built-in symbol with a macro, which allows us to then undefine the macro afterwards, which allows the built-in symbol to be visible again? I was confused because I was thinking that undefining __attribute__ was the cause of the original problem.
-erik
On Wed, May 27, 2015 at 10:48 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 27 May 2015, at 16:30, Roberto De Pietri roberto.depietri@unipr.it wrote:
Dear Comer:
I would like to confirm you that Ian and Eric were able to correctly find out the problem that originated the build problem on build using macports
- The HDF5 MacPorts port was updated from 1.8.14 to 1.8.15 on 16-May-2015
(https://trac.macports.org/log/trunk/dports/science/hdf5/Portfile), 2 days before the ET release
- HDF5 is undefining __attribute__, and this is creating site effect
(caused by including hdf5.h) that have standard c++ include to fail. This is true for gcc4.8 and gcc5.1
- A simple solution is to change the order of includes in the include
file: arrangements/Carpet/CarpetIOHDF5/src/CarpetIOHDF5.hh. you can replace this include with the one attached to the present mail.
This seems like a viable workaround until the problem is fixed in HDF5, so I propose that it be implemented in CarpetIOHDF5 and backported to the release branch.
- to have a fast start you may also copy the attached file:
osx-macports.run in simfactory/mdb/runscript.
- then set your local machine with the command
simfactory/bin/sim setup
- edit the local machine file you created (using the previous command) in
simfactory/mdb/machine to have:
*** ASSUMING MACPORT IS INSTALLED (subversion is needed cause the version that comes with XCOde *** will not work [new XCODE 6.3.2 and MacPorts 2.3.3]
sudo port install subversion sudo port install pkgconfig gcc49 fftw-3 gsl jpeg zlib hdf5 +fortran +gfortran openmpi openssl
### [FROM a MAIN DIRECTORY for the Cactus tree]
curl -kLO https://raw.githubusercontent.com/gridaphobe/CRL/ET_2015_05/GetComponents chmod a+x GetComponents ./GetComponents --parallel https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2015_05/einsteintoolki...
### [the enter in the cactus directory]
cd Cactus
cp [where_you_save_it]/CarpetIOHDF5.hh arrangements/Carpet/CarpetIOHDF5/src/ cp [where_you_save_it]/osx-macports.run simfactory/mdb/runscript simfactory/bin/sim setup
### [DO the local editing. In my case was the file named] ### the following line should be present ### ### optionlist = osx-macports.cfg ### runscript = osx-macports.run ### ppn = 4 ### max-num-threads = 4 ### num-threads = 1 ### nodes = 1 ### ### NOT: my machine is “iMac (27-inch, Late 2009)” ### OS X Yosemite 10.10.3 ### ### Processor Name: Intel Core i5 ### Processor Speed: 2,66 GHz ### Number of Processors: 1 ### Total Number of Cores: 4 ### L2 Cache (per Core): 256 KB ### L3 Cache: 8 MB ### Memory: 8 GB
simfactory/bin/sim build --thornlist thornlists/einsteintoolkit.th simfactory/bin/sim create-run static_tov --parfile=par/static_tov.par --proc=4 --num-threads=2
### Now the test TOV simulations should be running code is running on two process using two cores each.
## sudo port install python27 ## sudo port select —set python python27 ## sudo port install py-numpy py-scipy ## sudo port install py-matplotlib ## sudo port install py-h5py ## sudo port install py-ipython ## sudo port select —set ipython ipython27 ## ## ## TO SEE THE RESULTS:
ipython —-pylab
In [..]: FILE='/Users/depietri/simulations/static_tov/output-0000/static_tov/hydrobase-rho.maximum.asc' In [..]: d=loadtxt(FILE) In [..]: plot(d[:,1],d[:,2]*1e3,'k-') In [..]: ylim(1.25,1.30) In [..]: xlabel(r’time [CU c=1, G=1, $M_\odot$=1]') In [..]: ylabel(r'max($\rho \cdot 10^3$) [CU c=1, G=1, $M_\odot$=1]') In [..]:
<CarpetIOHDF5.hh><osx-macports.run>
Roberto De Pietri e-mail:roberto.depietri@fis.unipr.it Dipartimento di Fisica http://www.fis.unipr.it/~roberto.depietri Universita' di Parma tel: +39 (0521) 905280 Via G.P.Usberti 7/A fax: +39 (0521) 905223 I-43100 PARMA --- ITALY
-- Ian Hinder http://members.aei.mpg.de/ianhin
-- Erik Schnetter schnetter@cct.lsu.edu http://www.perimeterinstitute.ca/personal/eschnetter/
-- Ian Hinder http://members.aei.mpg.de/ianhin
On Thu, May 28, 2015 at 10:57 AM, Erik Schnetter schnetter@cct.lsu.edu wrote:
Originally, __attribute__ is a built-in keyword for the compiler. It is not a macro, as others suggested earlier. If you #define it to be empty, then the compiler will never see the keyword, as the preprocessor deletes it. So using #undef exactly undoes the action of the HDF5 header file, making the original keyword again visible to the compiler.
This sounds like a good idea to me. I'd suggest only doing the #undef for version 1.8.15 with the following check
((H5_VERS_MAJOR==1) && (H5_VERS_MINOR==8) && (H5_VERS_RELEASE==15)
since only that particular version is affected.
On Wed, May 20, 2015 at 2:26 PM, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
Oh well. You can find the contents of build3.log on http://pastebin.com/0q9NNAT4 and I note nothing different, or so it seems. Here is a query about mpich and openmpi on my system:
ComerMacProRetina:Cactus comerduncan$ port installed | grep mpich mpich-default @3.1.3_0+gcc49 mpich-default @3.1.4_0+gcc49 petsc @3.5.3_1+accelerate+hwloc+mpich ComerMacProRetina:Cactus comerduncan$ port installed | grep openmpi openmpi @1.7.5_3 (active) openmpi-default @1.7.5_3+gcc47 (active) petsc @3.5.3_1+accelerate+hwloc+openmpi (active)
Also, I note in the osx-macport config file that the compiler specified is gcc49 to wit:
CPP = cpp-mp-4.9 FPP = cpp-mp-4.9 CC = gcc-mp-4.9 CXX = g++-mp-4.9 F90 = gfortran-mp-4.9
However, note that the active openmpi-default points to gcc47. Could this be a problem?
I think not. Compilers are quite compatible. There is an issue with which libstdc++ is used, but MacPorts is careful to do the right thing for different compilers.
-erik
Thanks for your help.
Comer
On Wed, May 20, 2015 at 12:55 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 20 May 2015, at 18:35, Comer Duncan comer.duncan@gmail.com wrote:
Ok, I deactivated mpich and have run simfactory/bin/sim build --optionlist=osx-macports.cfg >build2.log 2>&1 and get similar errors. I have pasted the contents of build2.log to http://pastebin.com/kcua0vKQ. It does not seem that the deactivation of mpich had the desired effect.
You probably need to do a clean build by removing configs/sim and building again (this is usually good advice in general, if you suspect there is something weird happening with the build system). Having both MPI versions' header files around during compilation might have caused the problems.
-- Ian Hinder http://members.aei.mpg.de/ianhin
users@lists.einsteintoolkit.org
-
Barry Wardell -
Comer Duncan -
Erik Schnetter -
Frank Loeffler -
Ian Hinder -
Roberto De Pietri -
Steven R. Brandt