I have tried building ET for the current released version. I am on a macbook pro running Yosemite. The build script is:
#!/bin/sh rm -rf configs/sim echo "done removing configs/sim" simfactory/bin/sim build --optionlist=./myoptionlist.cfg --thornlist=./ cospluseinsteintkit.th >build$1.log 2>&1
The build goes along fine apparently until the final executable. I copy below the part after which the build chokes:
Creating cactus_sim in /Users/comerduncan/Cactus/exe from EinsteinAnalysis/ADMAnalysis EinsteinBase/ADMBase EinsteinBase/ADMCoupling EinsteinBase/ADMMacros AEIThorns/ADMMass AEIThorns/AEILocalInterp EinsteinAnalysis/AHFinder EinsteinAnalysis/AHFinderDirect ExternalLibraries/BLAS CactusBase/Boundary Cosmology/CT_Analytic Cosmology/CT_MultiLevel EinsteinAnalysis/CalcK Carpet/Carpet Carpet/CarpetEvolutionMask Carpet/CarpetIOASCII Carpet/CarpetIOBasic Carpet/CarpetIOHDF5 Carpet/CarpetIOScalar Carpet/CarpetIntegrateTest Carpet/CarpetInterp Carpet/CarpetInterp2 Carpet/CarpetLib Carpet/CarpetMask Carpet/CarpetProlongateTest Carpet/CarpetReduce Carpet/CarpetRegrid Carpet/CarpetRegrid2 Carpet/CarpetRegridTest Carpet/CarpetSlab Carpet/CarpetTracker CactusBase/CartGrid3D CactusNumerical/Cartoon2D EinsteinBase/Constants CactusBase/CoordBase EinsteinBase/CoordGauge Carpet/CycleClock CactusExamples/DemoInterp CactusNumerical/Dissipation EinsteinInitialData/DistortedBHIVP EinsteinAnalysis/EHFinder EinsteinBase/EOS_Base EinsteinEOS/EOS_Hybrid EinsteinEOS/EOS_IdealFluid EinsteinEOS/EOS_Omni EinsteinEOS/EOS_Polytrope EinsteinExact/EinsteinExact_Test CactusElliptic/EllBase CactusElliptic/EllSOR EinsteinInitialData/Exact EinsteinAnalysis/Extract ExternalLibraries/FFTW3 CactusExamples/FleshInfo CactusUtils/Formaline CactusBase/Fortran EinsteinEvolve/GRHydro EinsteinEvolve/GRHydro_InitData ExternalLibraries/GSL EinsteinExact/GaugeWave KrancNumericalTools/GenericFD ExternalLibraries/HDF5 CactusConnect/HTTPD CactusConnect/HTTPDExtra CactusExamples/HelloWorld Carpet/HighOrderWaveTest EinsteinBase/HydroBase EinsteinAnalysis/Hydro_Analysis EinsteinInitialData/Hydro_InitExcision EinsteinInitialData/IDAnalyticBH EinsteinInitialData/IDAxiBrillBH EinsteinInitialData/IDAxiOddBrillBH EinsteinInitialData/IDBrillData EinsteinInitialData/IDConstraintViolate EinsteinInitialData/IDFileADM EinsteinInitialData/IDLinearWaves CactusWave/IDScalarWave CactusWave/IDScalarWaveC CactusWave/IDScalarWaveCXX CactusWave/IDScalarWaveElliptic CactusExamples/IDWaveMoL CactusBase/IOASCII CactusBase/IOBasic CactusPUGHIO/IOHDF5 CactusPUGHIO/IOHDF5Util CactusIO/IOJpeg CactusBase/IOUtil CactusBase/InitBase CactusNumerical/InterpToArray EinsteinExact/KerrSchild ExternalLibraries/LAPACK ExternalLibraries/LORENE CactusNumerical/LocalInterp CactusNumerical/LocalInterp2 CactusNumerical/LocalReduce Carpet/LoopControl McLachlan/ML_ADMConstraints McLachlan/ML_ADMQuantities McLachlan/ML_BSSN McLachlan/ML_BSSN_Helper McLachlan/ML_BSSN_Test McLachlan/ML_CCZ4 McLachlan/ML_CCZ4_Helper McLachlan/ML_CCZ4_Test McLachlan/ML_WaveToy McLachlan/ML_WaveToy_Test ExternalLibraries/MPI CactusUtils/MemSpeed EinsteinInitialData/Meudon_Bin_BH EinsteinInitialData/Meudon_Bin_NS EinsteinInitialData/Meudon_Mag_NS EinsteinExact/Minkowski CactusNumerical/MoL EinsteinExact/ModifiedSchwarzschildBL EinsteinAnalysis/Multipole CactusUtils/NaNCatcher CactusUtils/NaNChecker EinsteinEvolve/NewRad CactusUtils/Nice EinsteinInitialData/NoExcision CactusUtils/NoMPI CactusNumerical/Noise CactusNumerical/Norms PITTNullCode/NullConstr PITTNullCode/NullDecomp PITTNullCode/NullEvolve PITTNullCode/NullExact PITTNullCode/NullGrid PITTNullCode/NullInterp PITTNullCode/NullNews PITTNullCode/NullPsiInt PITTNullCode/NullSHRExtract PITTNullCode/NullVars ExternalLibraries/OpenSSL EinsteinAnalysis/Outflow ExternalLibraries/PAPI CactusPUGH/PUGH CactusPUGH/PUGHInterp CactusPUGH/PUGHReduce CactusPUGH/PUGHSlab CactusNumerical/Periodic LSUThorns/PeriodicCarpet CactusExamples/Poisson AEIThorns/PunctureTracker LSUThorns/QuasiLocalMeasures Carpet/ReductionTest Carpet/ReductionTest2 Carpet/ReductionTest3 CactusNumerical/ReflectionSymmetry Carpet/RegridSyncTest EinsteinInitialData/RotatingDBHIVP CactusNumerical/RotatingSymmetry180 CactusNumerical/RotatingSymmetry90 CactusExamples/SampleBoundary CactusExamples/SampleIO EinsteinUtils/SetMask_SphericalSurface EinsteinExact/ShiftedGaugeWave CactusNumerical/Slab CactusNumerical/SlabTest CactusConnect/Socket CactusNumerical/SpaceMask PITTNullCode/SphericalHarmonicDecomp PITTNullCode/SphericalHarmonicRecon CactusNumerical/SphericalSurface EinsteinBase/StaticConformal LSUThorns/SummationByParts CactusBase/SymBase AEIThorns/SystemStatistics CactusUtils/SystemTopology CactusElliptic/TATelliptic EinsteinUtils/TGRtensor EinsteinInitialData/TOVSolver CactusUtils/TerminationTrigger CactusTest/TestArrays Carpet/TestCarpetGridInfo CactusTest/TestComplex CactusTest/TestCoordinates CactusTest/TestFortranCrayPointers CactusTest/TestFortranDependencies1 CactusTest/TestFortranDependencies2 CactusTest/TestFpointerNULL CactusTest/TestFreeF90 CactusTest/TestGlobalReduce CactusTest/TestInclude1 CactusTest/TestInclude2 CactusNumerical/TestLocalInterp2 CactusNumerical/TestLocalReduce CactusTest/TestLoop Carpet/TestLoopControl CactusTest/TestMath CactusTest/TestMoL CactusTest/TestPar CactusTest/TestReduce CactusTest/TestSchedule CactusTest/TestStrings CactusTest/TestTable CactusTest/TestTimers CactusTest/TestTypes CactusBase/Time CactusExamples/TimerInfo CactusUtils/TimerReport Carpet/Timers EinsteinBase/TmunuBase AEIThorns/Trigger EinsteinInitialData/TwoPunctures EinsteinExact/Vaidya2 LSUThorns/Vectors CactusWave/WaveBinarySource CactusExamples/WaveMoL CactusExamples/WaveToy1DF77 CactusExamples/WaveToy2DF77 CactusWave/WaveToyC CactusWave/WaveToyCXX CactusWave/WaveToyExtra CactusWave/WaveToyF77 CactusWave/WaveToyF90 CactusWave/WaveToyFreeF90 EinsteinAnalysis/WeylScal4 ExternalLibraries/hwloc ExternalLibraries/libjpeg ExternalLibraries/zlib Formaline: Creating git master repository... Formaline: Pushing source tree to master git repository... 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_CT_MultiLevel.a(CT_MultiLevel.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) ... "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_CT_MultiLevel.a(CT_MultiLevel.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) ... "_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_CT_MultiLevel.a(CT_MultiLevel.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) ... 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[1]: *** Waiting for unfinished jobs.... Formaline: Pushing to local repository /Users/comerduncan/Cactus/../CactusSourceJar.git... Formaline: Optimising git repository (slow only the first time)... make: *** [sim] Error 2
Is there likely a problem with openmpi again?? Here is some info about the current ports:
port installed | grep openmpi Warning: port definitions are more than two weeks old, consider updating them by running 'port selfupdate'. openmpi @1.7.5_3 openmpi-default @1.7.5_3+gcc49 (active) openmpi-default @1.7.5_4+gcc49 openmpi-gcc49 @1.7.5_3+fortran (active) openmpi-gcc49 @1.7.5_4+fortran
Note that I had elected to activate openmpi-gcc49 @1.7.5_3+fortran (active) rather than openmpi-gcc49 @1.7.5_4+fortran because with _4 the build crashed.
For gcc49 there is:
gcc49 @4.9.2_1 gcc49 @4.9.2_2 (active) mpich-default @3.1.3_0+gcc49 mpich-default @3.1.4_0+gcc49 openmpi-default @1.7.5_3+gcc49 (active) openmpi-default @1.7.5_4+gcc49 openmpi-gcc49 @1.7.5_3+fortran (active) openmpi-gcc49 @1.7.5_4+fortran
I am also using the macports hdf5 patched:
port installed | grep hdf5
hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.15-patch1_0+cxx+fortran+gfortran (active)
Can I get some further help on resolving this? I have not updated macports in a few weeks as I did not want to possibly pollute what did work a while back.
Thanks.
Comer
On 07/06/2015 02:30 PM, Comer Duncan wrote:
I have tried building ET for the current released version. I am on a macbook pro running Yosemite. The build script is:
#!/bin/sh rm -rf configs/sim echo "done removing configs/sim" simfactory/bin/sim build --optionlist=./myoptionlist.cfg --thornlist=./cospluseinsteintkit.th http://cospluseinsteintkit.th
build$1.log 2>&1
What's in "myoptionlist.cfg"?
Cheers, Steve
The build goes along fine apparently until the final executable. I copy below the part after which the build chokes:
Creating cactus_sim in /Users/comerduncan/Cactus/exe from EinsteinAnalysis/ADMAnalysis EinsteinBase/ADMBase EinsteinBase/ADMCoupling EinsteinBase/ADMMacros AEIThorns/ADMMass AEIThorns/AEILocalInterp EinsteinAnalysis/AHFinder EinsteinAnalysis/AHFinderDirect ExternalLibraries/BLAS CactusBase/Boundary Cosmology/CT_Analytic Cosmology/CT_MultiLevel EinsteinAnalysis/CalcK Carpet/Carpet Carpet/CarpetEvolutionMask Carpet/CarpetIOASCII Carpet/CarpetIOBasic Carpet/CarpetIOHDF5 Carpet/CarpetIOScalar Carpet/CarpetIntegrateTest Carpet/CarpetInterp Carpet/CarpetInterp2 Carpet/CarpetLib Carpet/CarpetMask Carpet/CarpetProlongateTest Carpet/CarpetReduce Carpet/CarpetRegrid Carpet/CarpetRegrid2 Carpet/CarpetRegridTest Carpet/CarpetSlab Carpet/CarpetTracker CactusBase/CartGrid3D CactusNumerical/Cartoon2D EinsteinBase/Constants CactusBase/CoordBase EinsteinBase/CoordGauge Carpet/CycleClock CactusExamples/DemoInterp CactusNumerical/Dissipation EinsteinInitialData/DistortedBHIVP EinsteinAnalysis/EHFinder EinsteinBase/EOS_Base EinsteinEOS/EOS_Hybrid EinsteinEOS/EOS_IdealFluid EinsteinEOS/EOS_Omni EinsteinEOS/EOS_Polytrope EinsteinExact/EinsteinExact_Test CactusElliptic/EllBase CactusElliptic/EllSOR EinsteinInitialData/Exact EinsteinAnalysis/Extract ExternalLibraries/FFTW3 CactusExamples/FleshInfo CactusUtils/Formaline CactusBase/Fortran EinsteinEvolve/GRHydro EinsteinEvolve/GRHydro_InitData ExternalLibraries/GSL EinsteinExact/GaugeWave KrancNumericalTools/GenericFD ExternalLibraries/HDF5 CactusConnect/HTTPD CactusConnect/HTTPDExtra CactusExamples/HelloWorld Carpet/HighOrderWaveTest EinsteinBase/HydroBase EinsteinAnalysis/Hydro_Analysis EinsteinInitialData/Hydro_InitExcision EinsteinInitialData/IDAnalyticBH EinsteinInitialData/IDAxiBrillBH EinsteinInitialData/IDAxiOddBrillBH EinsteinInitialData/IDBrillData EinsteinInitialData/IDConstraintViolate EinsteinInitialData/IDFileADM EinsteinInitialData/IDLinearWaves CactusWave/IDScalarWave CactusWave/IDScalarWaveC CactusWave/IDScalarWaveCXX CactusWave/IDScalarWaveElliptic CactusExamples/IDWaveMoL CactusBase/IOASCII CactusBase/IOBasic CactusPUGHIO/IOHDF5 CactusPUGHIO/IOHDF5Util CactusIO/IOJpeg CactusBase/IOUtil CactusBase/InitBase CactusNumerical/InterpToArray EinsteinExact/KerrSchild ExternalLibraries/LAPACK ExternalLibraries/LORENE CactusNumerical/LocalInterp CactusNumerical/LocalInterp2 CactusNumerical/LocalReduce Carpet/LoopControl McLachlan/ML_ADMConstraints McLachlan/ML_ADMQuantities McLachlan/ML_BSSN McLachlan/ML_BSSN_Helper McLachlan/ML_BSSN_Test McLachlan/ML_CCZ4 McLachlan/ML_CCZ4_Helper McLachlan/ML_CCZ4_Test McLachlan/ML_WaveToy McLachlan/ML_WaveToy_Test ExternalLibraries/MPI CactusUtils/MemSpeed EinsteinInitialData/Meudon_Bin_BH EinsteinInitialData/Meudon_Bin_NS EinsteinInitialData/Meudon_Mag_NS EinsteinExact/Minkowski CactusNumerical/MoL EinsteinExact/ModifiedSchwarzschildBL EinsteinAnalysis/Multipole CactusUtils/NaNCatcher CactusUtils/NaNChecker EinsteinEvolve/NewRad CactusUtils/Nice EinsteinInitialData/NoExcision CactusUtils/NoMPI CactusNumerical/Noise CactusNumerical/Norms PITTNullCode/NullConstr PITTNullCode/NullDecomp PITTNullCode/NullEvolve PITTNullCode/NullExact PITTNullCode/NullGrid PITTNullCode/NullInterp PITTNullCode/NullNews PITTNullCode/NullPsiInt PITTNullCode/NullSHRExtract PITTNullCode/NullVars ExternalLibraries/OpenSSL EinsteinAnalysis/Outflow ExternalLibraries/PAPI CactusPUGH/PUGH CactusPUGH/PUGHInterp CactusPUGH/PUGHReduce CactusPUGH/PUGHSlab CactusNumerical/Periodic LSUThorns/PeriodicCarpet CactusExamples/Poisson AEIThorns/PunctureTracker LSUThorns/QuasiLocalMeasures Carpet/ReductionTest Carpet/ReductionTest2 Carpet/ReductionTest3 CactusNumerical/ReflectionSymmetry Carpet/RegridSyncTest EinsteinInitialData/RotatingDBHIVP CactusNumerical/RotatingSymmetry180 CactusNumerical/RotatingSymmetry90 CactusExamples/SampleBoundary CactusExamples/SampleIO EinsteinUtils/SetMask_SphericalSurface EinsteinExact/ShiftedGaugeWave CactusNumerical/Slab CactusNumerical/SlabTest CactusConnect/Socket CactusNumerical/SpaceMask PITTNullCode/SphericalHarmonicDecomp PITTNullCode/SphericalHarmonicRecon CactusNumerical/SphericalSurface EinsteinBase/StaticConformal LSUThorns/SummationByParts CactusBase/SymBase AEIThorns/SystemStatistics CactusUtils/SystemTopology CactusElliptic/TATelliptic EinsteinUtils/TGRtensor EinsteinInitialData/TOVSolver CactusUtils/TerminationTrigger CactusTest/TestArrays Carpet/TestCarpetGridInfo CactusTest/TestComplex CactusTest/TestCoordinates CactusTest/TestFortranCrayPointers CactusTest/TestFortranDependencies1 CactusTest/TestFortranDependencies2 CactusTest/TestFpointerNULL CactusTest/TestFreeF90 CactusTest/TestGlobalReduce CactusTest/TestInclude1 CactusTest/TestInclude2 CactusNumerical/TestLocalInterp2 CactusNumerical/TestLocalReduce CactusTest/TestLoop Carpet/TestLoopControl CactusTest/TestMath CactusTest/TestMoL CactusTest/TestPar CactusTest/TestReduce CactusTest/TestSchedule CactusTest/TestStrings CactusTest/TestTable CactusTest/TestTimers CactusTest/TestTypes CactusBase/Time CactusExamples/TimerInfo CactusUtils/TimerReport Carpet/Timers EinsteinBase/TmunuBase AEIThorns/Trigger EinsteinInitialData/TwoPunctures EinsteinExact/Vaidya2 LSUThorns/Vectors CactusWave/WaveBinarySource CactusExamples/WaveMoL CactusExamples/WaveToy1DF77 CactusExamples/WaveToy2DF77 CactusWave/WaveToyC CactusWave/WaveToyCXX CactusWave/WaveToyExtra CactusWave/WaveToyF77 CactusWave/WaveToyF90 CactusWave/WaveToyFreeF90 EinsteinAnalysis/WeylScal4 ExternalLibraries/hwloc ExternalLibraries/libjpeg ExternalLibraries/zlib Formaline: Creating git master repository... Formaline: Pushing source tree to master git repository... 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_CT_MultiLevel.a(CT_MultiLevel.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) ... "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_CT_MultiLevel.a(CT_MultiLevel.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) ... "_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_CT_MultiLevel.a(CT_MultiLevel.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) ... 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[1]: *** Waiting for unfinished jobs.... Formaline: Pushing to local repository /Users/comerduncan/Cactus/../CactusSourceJar.git... Formaline: Optimising git repository (slow only the first time)... make: *** [sim] Error 2
Is there likely a problem with openmpi again?? Here is some info about the current ports:
port installed | grep openmpi Warning: port definitions are more than two weeks old, consider updating them by running 'port selfupdate'. openmpi @1.7.5_3 openmpi-default @1.7.5_3+gcc49 (active) openmpi-default @1.7.5_4+gcc49 openmpi-gcc49 @1.7.5_3+fortran (active) openmpi-gcc49 @1.7.5_4+fortran
Note that I had elected to activate openmpi-gcc49 @1.7.5_3+fortran (active) rather than openmpi-gcc49 @1.7.5_4+fortran because with _4 the build crashed.
For gcc49 there is:
gcc49 @4.9.2_1 gcc49 @4.9.2_2 (active) mpich-default @3.1.3_0+gcc49 mpich-default @3.1.4_0+gcc49 openmpi-default @1.7.5_3+gcc49 (active) openmpi-default @1.7.5_4+gcc49 openmpi-gcc49 @1.7.5_3+fortran (active) openmpi-gcc49 @1.7.5_4+fortran
I am also using the macports hdf5 patched:
port installed | grep hdf5
hdf5 @1.8.13_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+gcc46 hdf5 @1.8.14_0+cxx+fortran+gfortran hdf5 @1.8.15-patch1_0+cxx+fortran+gfortran (active)
Can I get some further help on resolving this? I have not updated macports in a few weeks as I did not want to possibly pollute what did work a while back.
Thanks.
Comer
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Mon, Jul 06, 2015 at 03:30:13PM -0400, Comer Duncan wrote:
I have tried building ET for the current released version. I am on a macbook pro running Yosemite. The build script is:
On first glance, this looks like a problem with a missing c++ mpi interface (again?). It would be interesting to see your option list and a verbose link line.
Frank
Comer, thank you for sending the optionlist. I see that you have
MPI_DIR = /opt/local
The expectation is that the system can find the mpi c++ compiler wrapper in $(MPI_DIR)/bin. Is that the case? The mpi c++ compiler wrapper may have any of the following names: mpic++, mpiCC, mpicxx, or mpicxx-openmpi-mp.
If the mpi c++ wrapper is in your path, then you could simply try unsetting the MPI_DIR variable and building.
Cheers, Steve
On 07/06/2015 05:33 PM, Frank Loeffler wrote:
On Mon, Jul 06, 2015 at 03:30:13PM -0400, Comer Duncan wrote:
I have tried building ET for the current released version. I am on a macbook pro running Yosemite. The build script is:
On first glance, this looks like a problem with a missing c++ mpi interface (again?). It would be interesting to see your option list and a verbose link line.
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
HI Steve,
I have reset MPI_DIR= ,i.e. not even a blank and rebuilt, but still get the same crash complaints. Am I to set MPI_DIR to something else?
I note that in May I had issues with builds in part due to the mpicc vs mpiCC problem on macs. Then in the dev version detect.pl was changed to put mpiCC last so the mac would not be as confused. I am using the latest release of ET and have looked at the detect.pl file with that. It does not have the reordering of the search list for mpicc with mpiCC put last, as did the dev version. Somehow I have been assuming that the change to detect.pl had been backported to Hilbert, but apparently not?? So, is it reasonable to replace the released Hilbert version of detect.pl with the dev-fixed version? If that can be done safely I could give that a try.
Thanks for all who help.
Comer
On Tue, Jul 7, 2015 at 9:08 AM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
Comer, thank you for sending the optionlist. I see that you have
MPI_DIR = /opt/local
The expectation is that the system can find the mpi c++ compiler wrapper in $(MPI_DIR)/bin. Is that the case? The mpi c++ compiler wrapper may have any of the following names: mpic++, mpiCC, mpicxx, or mpicxx-openmpi-mp.
If the mpi c++ wrapper is in your path, then you could simply try unsetting the MPI_DIR variable and building.
Cheers, Steve
On 07/06/2015 05:33 PM, Frank Loeffler wrote:
On Mon, Jul 06, 2015 at 03:30:13PM -0400, Comer Duncan wrote:
I have tried building ET for the current released version. I am on a macbook pro running Yosemite. The build script is:
On first glance, this looks like a problem with a missing c++ mpi interface (again?). It would be interesting to see your option list and a verbose link line.
Frank
Users mailing listUsers@einsteintoolkit.orghttp://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 7 Jul 2015, at 18:55, Comer Duncan comer.duncan@gmail.com wrote:
HI Steve,
I have reset MPI_DIR= ,i.e. not even a blank and rebuilt, but still get the same crash complaints. Am I to set MPI_DIR to something else?
I note that in May I had issues with builds in part due to the mpicc vs mpiCC problem on macs. Then in the dev version detect.pl was changed to put mpiCC last so the mac would not be as confused. I am using the latest release of ET and have looked at the detect.pl file with that. It does not have the reordering of the search list for mpicc with mpiCC put last, as did the dev version. Somehow I have been assuming that the change to detect.pl had been backported to Hilbert, but apparently not?? So, is it reasonable to replace the released Hilbert version of detect.pl with the dev-fixed version? If that can be done safely I could give that a try.
Thanks for all who help.
Hi Comer,
Maybe I missed it, but have you tried using the osx-macports.cfg optionlist that we provide? We tested this, and it worked at the time, with the list of macports packages. I now see you are using a different optionlist. Does the one in simfactory no longer work? Is the issue that you are using the release, and a needed fix has not been backported?
Comer
On Tue, Jul 7, 2015 at 9:08 AM, Steven R. Brandt sbrandt@cct.lsu.edu wrote: Comer, thank you for sending the optionlist. I see that you have
MPI_DIR = /opt/local
The expectation is that the system can find the mpi c++ compiler wrapper in $(MPI_DIR)/bin. Is that the case? The mpi c++ compiler wrapper may have any of the following names: mpic++, mpiCC, mpicxx, or mpicxx-openmpi-mp.
If the mpi c++ wrapper is in your path, then you could simply try unsetting the MPI_DIR variable and building.
Cheers, Steve
On 07/06/2015 05:33 PM, Frank Loeffler wrote:
On Mon, Jul 06, 2015 at 03:30:13PM -0400, Comer Duncan wrote:
I have tried building ET for the current released version. I am on a macbook pro running Yosemite. The build script is:
On first glance, this looks like a problem with a missing c++ mpi interface (again?). It would be interesting to see your option list and a verbose link line.
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hi Ian,
The cfg file I use _is_ the same as the stock osx_macports.cfg. Now however I have, after Steve's suggestion, replaced "MPI_DIR=/opt/local" with "MPI_DIR=" (ie nothing) and tried to build with that. If this assignment needs to be something else, I need for the developers to confirm that. So, I have already tried the stock optionlist with a crash as the result. I sent to query about replacing detect.pl with the version which puts mpiCC last, as that was what I used when I was using the dev version. I am using Hilbert now, since using the dev version resulted in a problem due to it being the case that one day a few weeks ago a change in the dev version resulted in the build crashing. Sticking with Hilbert is what I will do. So my question was can I go ahead and replace the Hilbert detect.pl with the dev version of detect.pl. While I think this is likely ok, I want to proceed carefully.
I am also looking at the compatibility issue among the various components mpicc, mpixx, openmpi, and hdf5. I am using the patched flavor of hdf5. A while back you thought that the patched version of hdf5 was ok to use, so that is what I am doing (ie the hdf5 is HDF5_DIR = /opt/local).
The problem I was having was that some updates to macports resulted in inadvertently inducing inconsistencies/incompatibilities dooming the builds. Very frustrating. I have not done a macports update in at least two weeks and have checked the versions of the compiled mpicc, mpixx, openmpi and hdf5 and so far see no problems....I obviously must be missing something if compatibility is the problem. And I will not do a macports update until I can be sure of its effects on the ET builds on my mac running Yosemite.
Please have patience. Believe me, I want to get to the use of Eloisa's CT_Multilevel thorn as soon as possible!
Comer
On Tue, Jul 7, 2015 at 1:39 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 7 Jul 2015, at 18:55, Comer Duncan comer.duncan@gmail.com wrote:
HI Steve,
I have reset MPI_DIR= ,i.e. not even a blank and rebuilt, but still get the same crash complaints. Am I to set MPI_DIR to something else?
I note that in May I had issues with builds in part due to the mpicc vs mpiCC problem on macs. Then in the dev version detect.pl was changed to put mpiCC last so the mac would not be as confused. I am using the latest release of ET and have looked at the detect.pl file with that. It does not have the reordering of the search list for mpicc with mpiCC put last, as did the dev version. Somehow I have been assuming that the change to detect.pl had been backported to Hilbert, but apparently not?? So, is it reasonable to replace the released Hilbert version of detect.pl with the dev-fixed version? If that can be done safely I could give that a try.
Thanks for all who help.
Hi Comer,
Maybe I missed it, but have you tried using the osx-macports.cfg optionlist that we provide? We tested this, and it worked at the time, with the list of macports packages. I now see you are using a different optionlist. Does the one in simfactory no longer work? Is the issue that you are using the release, and a needed fix has not been backported?
Comer
On Tue, Jul 7, 2015 at 9:08 AM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
Comer, thank you for sending the optionlist. I see that you have
MPI_DIR = /opt/local
The expectation is that the system can find the mpi c++ compiler wrapper in $(MPI_DIR)/bin. Is that the case? The mpi c++ compiler wrapper may have any of the following names: mpic++, mpiCC, mpicxx, or mpicxx-openmpi-mp.
If the mpi c++ wrapper is in your path, then you could simply try unsetting the MPI_DIR variable and building.
Cheers, Steve
On 07/06/2015 05:33 PM, Frank Loeffler wrote:
On Mon, Jul 06, 2015 at 03:30:13PM -0400, Comer Duncan wrote:
I have tried building ET for the current released version. I am on a macbook pro running Yosemite. The build script is:
On first glance, this looks like a problem with a missing c++ mpi interface (again?). It would be interesting to see your option list and a verbose link line.
Frank
Users mailing listUsers@einsteintoolkit.orghttp://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Ian Hinder http://members.aei.mpg.de/ianhin
I have now built and executed Hilbert. I have done a couple of builds, one with MPI_DIR set to nothing and one with MPI_DIR set to /opt/local. Both build and seem to work. I had replaced the released version of the file detect.pl with the development version. So, the bottom line seems simple: the culprit was the detect.pl.
Please let me know if you think my conclusions have issues. Otherwise, I suggest that the dev version of detect.pl be back-ported to the existing Hilbert release. Thus no change is needed in the Hilbert version of osx-macports.cfg.
Thanks to all you helped me sort out this.
Comer
On Tue, Jul 7, 2015 at 2:07 PM, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
The cfg file I use _is_ the same as the stock osx_macports.cfg. Now however I have, after Steve's suggestion, replaced "MPI_DIR=/opt/local" with "MPI_DIR=" (ie nothing) and tried to build with that. If this assignment needs to be something else, I need for the developers to confirm that. So, I have already tried the stock optionlist with a crash as the result. I sent to query about replacing detect.pl with the version which puts mpiCC last, as that was what I used when I was using the dev version. I am using Hilbert now, since using the dev version resulted in a problem due to it being the case that one day a few weeks ago a change in the dev version resulted in the build crashing. Sticking with Hilbert is what I will do. So my question was can I go ahead and replace the Hilbert detect.pl with the dev version of detect.pl. While I think this is likely ok, I want to proceed carefully.
I am also looking at the compatibility issue among the various components mpicc, mpixx, openmpi, and hdf5. I am using the patched flavor of hdf5. A while back you thought that the patched version of hdf5 was ok to use, so that is what I am doing (ie the hdf5 is HDF5_DIR = /opt/local).
The problem I was having was that some updates to macports resulted in inadvertently inducing inconsistencies/incompatibilities dooming the builds. Very frustrating. I have not done a macports update in at least two weeks and have checked the versions of the compiled mpicc, mpixx, openmpi and hdf5 and so far see no problems....I obviously must be missing something if compatibility is the problem. And I will not do a macports update until I can be sure of its effects on the ET builds on my mac running Yosemite.
Please have patience. Believe me, I want to get to the use of Eloisa's CT_Multilevel thorn as soon as possible!
Comer
On Tue, Jul 7, 2015 at 1:39 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 7 Jul 2015, at 18:55, Comer Duncan comer.duncan@gmail.com wrote:
HI Steve,
I have reset MPI_DIR= ,i.e. not even a blank and rebuilt, but still get the same crash complaints. Am I to set MPI_DIR to something else?
I note that in May I had issues with builds in part due to the mpicc vs mpiCC problem on macs. Then in the dev version detect.pl was changed to put mpiCC last so the mac would not be as confused. I am using the latest release of ET and have looked at the detect.pl file with that. It does not have the reordering of the search list for mpicc with mpiCC put last, as did the dev version. Somehow I have been assuming that the change to detect.pl had been backported to Hilbert, but apparently not?? So, is it reasonable to replace the released Hilbert version of detect.pl with the dev-fixed version? If that can be done safely I could give that a try.
Thanks for all who help.
Hi Comer,
Maybe I missed it, but have you tried using the osx-macports.cfg optionlist that we provide? We tested this, and it worked at the time, with the list of macports packages. I now see you are using a different optionlist. Does the one in simfactory no longer work? Is the issue that you are using the release, and a needed fix has not been backported?
Comer
On Tue, Jul 7, 2015 at 9:08 AM, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
Comer, thank you for sending the optionlist. I see that you have
MPI_DIR = /opt/local
The expectation is that the system can find the mpi c++ compiler wrapper in $(MPI_DIR)/bin. Is that the case? The mpi c++ compiler wrapper may have any of the following names: mpic++, mpiCC, mpicxx, or mpicxx-openmpi-mp.
If the mpi c++ wrapper is in your path, then you could simply try unsetting the MPI_DIR variable and building.
Cheers, Steve
On 07/06/2015 05:33 PM, Frank Loeffler wrote:
On Mon, Jul 06, 2015 at 03:30:13PM -0400, Comer Duncan wrote:
I have tried building ET for the current released version. I am on a macbook pro running Yosemite. The build script is:
On first glance, this looks like a problem with a missing c++ mpi interface (again?). It would be interesting to see your option list and a verbose link line.
Frank
Users mailing listUsers@einsteintoolkit.orghttp://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Ian Hinder http://members.aei.mpg.de/ianhin
On 7 Jul 2015, at 23:04, Comer Duncan comer.duncan@gmail.com wrote:
I have now built and executed Hilbert. I have done a couple of builds, one with MPI_DIR set to nothing and one with MPI_DIR set to /opt/local. Both build and seem to work. I had replaced the released version of the file detect.pl with the development version. So, the bottom line seems simple: the culprit was the detect.pl.
Please let me know if you think my conclusions have issues. Otherwise, I suggest that the dev version of detect.pl be back-ported to the existing Hilbert release. Thus no change is needed in the Hilbert version of osx-macports.cfg.
Thanks to all you helped me sort out this.
Thanks for noticing the problem! I have created a ticket (https://trac.einsteintoolkit.org/ticket/1794) for the backport. I don't have time right now to do this, but maybe someone else does?
Thanks!
On Wed, Jul 8, 2015 at 3:43 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 7 Jul 2015, at 23:04, Comer Duncan comer.duncan@gmail.com wrote:
I have now built and executed Hilbert. I have done a couple of builds, one with MPI_DIR set to nothing and one with MPI_DIR set to /opt/local. Both build and seem to work. I had replaced the released version of the file detect.pl with the development version. So, the bottom line seems simple: the culprit was the detect.pl.
Please let me know if you think my conclusions have issues. Otherwise, I suggest that the dev version of detect.pl be back-ported to the existing Hilbert release. Thus no change is needed in the Hilbert version of osx-macports.cfg.
Thanks to all you helped me sort out this.
Thanks for noticing the problem! I have created a ticket ( https://trac.einsteintoolkit.org/ticket/1794) for the backport. I don't have time right now to do this, but maybe someone else does?
-- Ian Hinder http://members.aei.mpg.de/ianhin
users@lists.einsteintoolkit.org
-
Comer Duncan -
Frank Loeffler -
Ian Hinder -
Steven R. Brandt