From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-16 15:38:52
|
All - I'd like to merge the automake branch. My plan is (1) copy the current trunk to branches/libmesh-0.8.0 in case anything else needs to be resolved for that release feature (2) merge the libmesh.automake branch back to trunk are there any outstanding uncommitted changes on trunk I need to hold off for? -Ben |
From: Roy S. <roy...@ic...> - 2012-11-16 16:43:27
|
forgot to copy to list On Fri, 16 Nov 2012, Roy Stogner wrote: > > On Fri, 16 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote: > >> are there any outstanding uncommitted changes on trunk I need to hold off >> for? > > There might be another ParallelMesh-with-repartitioning fix coming > soon, but nothing from me that should prevent the fork / merge. > --- > Roy > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-19 14:44:07
|
On Nov 19, 2012, at 8:39 AM, Robert <li...@ro...> wrote: > My older installation of libmesh (r5498) works fine on the same computer with MPI. Even with > "make V=0" I could not get more information about the compilerflags used, so I cannot really > figure out, if it is a problem on my side or the build-system. Well the problem is that the MPI configuration is not being determined properly, but the question is why. Can you post the summary information from configure (where it prints all that) and also send me your config.log? configure should still be looking preferentially for the MPI compilers and then falling back to snooping the MPI configuration from PETSc, so this should be a straightforward fix. -Ben |
From: Robert <li...@ro...> - 2012-11-19 15:15:09
Attachments:
config.log
|
On Mon, Nov 19, 2012 at 08:43:52AM -0600, Kirk, Benjamin (JSC-EG311) wrote: > > On Nov 19, 2012, at 8:39 AM, Robert <li...@ro...> wrote: > > > My older installation of libmesh (r5498) works fine on the same computer with MPI. Even with > > "make V=0" I could not get more information about the compilerflags used, so I cannot really > > figure out, if it is a problem on my side or the build-system. > > > Well the problem is that the MPI configuration is not being determined properly, but the question is why. Can you post the summary information from configure (where it prints all that) and also send me your config.log? > > configure should still be looking preferentially for the MPI compilers and then falling back to snooping the MPI configuration from PETSc, so this should be a straightforward fix. > The configure summary is pasted below and the config.log is attached ----------------------------------- SUMMARY ----------------------------------- Package version.................... : libmesh-0.9.0 C++ compiler type.................. : gcc4.5 C++ compiler....................... : g++ C compiler......................... : gcc Fortran compiler................... : gfortran Build Method....................... : opt CPPFLAGS........................... : -DNDEBUG CXXFLAGS........................... : -O2 -felide-constructors -funroll-loops -fstrict-aliasing -std=c++0x -Wdisabled-optimization -fopenmp CFLAGS............................. : -O2 -funroll-loops -fstrict-aliasing -fopenmp Install dir........................ : /tmp/libmesh Build user......................... : weidlich Build host......................... : stokes Configure date..................... : 2012-11-19 15:26 Build architecture................. : x86_64-unknown-linux-gnu SVN revision number................ : 6404 Library Features: adaptive mesh refinement......... : yes complex variables................ : no ghosted vectors.................. : yes high-order shape functions....... : yes infinite elements................ : no Dirichlet constraints............ : yes node constraints................. : no parallel mesh.................... : no performance logging.............. : no periodic boundary conditions..... : yes reference counting............... : yes shape function 2nd derivatives... : yes stack trace files................ : no subdomain id size................ : 2 bytes variational smoother............. : yes xdr binary I/O................... : yes Optional Packages: boost............................ : yes eigen............................ : no exodus........................... : yes fparser.......................... : yes build from version............ : release glpk............................. : no gmv.............................. : yes gzstream......................... : yes laspack.......................... : yes libhilbert....................... : yes metis............................ : yes mpi.............................. : yes nemesis.......................... : yes netcdf........................... : yes openmp........................... : yes parmetis......................... : yes petsc............................ : yes version....................... : 3.2.0 sfcurves......................... : yes slepc............................ : no tbb.............................. : no c++ threads...................... : no tecio............................ : no tecplot...(vendor binaries)...... : yes tetgen........................... : yes triangle......................... : yes trilinos......................... : yes AztecOO....................... : no NOX........................... : no ML............................ : no vtk.............................. : yes libmesh_optional_INCLUDES........ : -I/home/xxxx/opt/include/vtk-5.6 -I/home/xxxx/opt/build/petsc-3.2-p6/include -I/home/xxxx/opt/build/petsc-3.2-p6/linux-gnu-opt/include -I/usr/include libmesh_optional_LIBS............ : -Wl,-rpath,/home/xxxx/opt/lib/vtk-5.6 -L/home/xxxx/opt/lib/vtk-5.6 -lvtkIO -lvtkCommon -lvtkFiltering -lz -L/home/xxxx/opt/build/petsc-3.2-p6/linux-gnu-opt/lib -lpetsc -lX11 -Wl,-rpath,/home/xxxx/opt/build/petsc-3.2-p6/linux-gnu-opt/lib -lcmumps -ldmumps -lsmumps -lzmumps -lmumps_common -lpord -lparmetis -lmetis -lsuperlu_4.2 -lscalapack -lblacs -lflapack -lfblas -L/usr/lib64/gcc/x86_64-suse-linux/4.5 -L/global/linux/64_bit/opt/intel/mkl/10.2.2.025/lib/em64t -L/global/linux/64_bit/opt/intel/mkl/10.2.2.025/lib/32 -L/global/linux/64_bit/opt/intel/mkl/10.2.2.025/lib/64 -L/usr/x86_64-suse-linux/lib -lmpichf90 -lgfortran -lm -lmpich -lopa -lmpl -lrt -lpthread -lgcc_s -ldl ------------------------------------------------------------------------------- Configure complete, now type 'make' and then 'make install'. --------------------------------------------- --------- Done Configuring libMesh ---------- --------------------------------------------- |
From: Roy S. <roy...@ic...> - 2012-11-16 18:17:37
|
On Fri, 16 Nov 2012, Roy Stogner wrote: >> There might be another ParallelMesh-with-repartitioning fix coming >> soon, but nothing from me that should prevent the fork / merge. Actually, I'll have a few Cygwin fixes coming in too. I'll check for branched-out-from-under-me before committing them, though. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-16 18:37:35
|
Thanks. I won't do this until the evening at the earliest. -Ben On Nov 16, 2012, at 12:17 PM, "Roy Stogner" <roy...@ic...> wrote: > On Fri, 16 Nov 2012, Roy Stogner wrote: > >>> There might be another ParallelMesh-with-repartitioning fix coming >>> soon, but nothing from me that should prevent the fork / merge. > > Actually, I'll have a few Cygwin fixes coming in too. I'll check for > branched-out-from-under-me before committing them, though. > --- > Roy > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-19 15:28:33
|
Very good, thanks. Where on your system is MPI actually installed? The issue is that the Parmetis makefile is not inheriting every -I…. that libMesh is using, which is actually the way I want it. In particular, it is not getting all of libmesh_optional_INCLUDES But the only thing I suspect there is that your MPI lives in /usr/include, which should not *need* to be specified. Thanks, -Ben On Nov 19, 2012, at 9:14 AM, Robert <li...@ro...> wrote: > > > On Mon, Nov 19, 2012 at 08:43:52AM -0600, Kirk, Benjamin (JSC-EG311) wrote: >> >> On Nov 19, 2012, at 8:39 AM, Robert <li...@ro...> wrote: >> >>> My older installation of libmesh (r5498) works fine on the same computer with MPI. Even with >>> "make V=0" I could not get more information about the compilerflags used, so I cannot really >>> figure out, if it is a problem on my side or the build-system. >> >> >> Well the problem is that the MPI configuration is not being determined properly, but the question is why. Can you post the summary information from configure (where it prints all that) and also send me your config.log? >> >> configure should still be looking preferentially for the MPI compilers and then falling back to snooping the MPI configuration from PETSc, so this should be a straightforward fix. >> > > > The configure summary is pasted below and the config.log is attached > > ----------------------------------- SUMMARY ----------------------------------- > > Package version.................... : libmesh-0.9.0 > > C++ compiler type.................. : gcc4.5 > C++ compiler....................... : g++ > C compiler......................... : gcc > Fortran compiler................... : gfortran > Build Method....................... : opt > CPPFLAGS........................... : -DNDEBUG > CXXFLAGS........................... : -O2 -felide-constructors -funroll-loops -fstrict-aliasing -std=c++0x -Wdisabled-optimization -fopenmp > CFLAGS............................. : -O2 -funroll-loops -fstrict-aliasing -fopenmp > Install dir........................ : /tmp/libmesh > Build user......................... : weidlich > Build host......................... : stokes > Configure date..................... : 2012-11-19 15:26 > Build architecture................. : x86_64-unknown-linux-gnu > SVN revision number................ : 6404 > > Library Features: > adaptive mesh refinement......... : yes > complex variables................ : no > ghosted vectors.................. : yes > high-order shape functions....... : yes > infinite elements................ : no > Dirichlet constraints............ : yes > node constraints................. : no > parallel mesh.................... : no > performance logging.............. : no > periodic boundary conditions..... : yes > reference counting............... : yes > shape function 2nd derivatives... : yes > stack trace files................ : no > subdomain id size................ : 2 bytes > variational smoother............. : yes > xdr binary I/O................... : yes > > Optional Packages: > boost............................ : yes > eigen............................ : no > exodus........................... : yes > fparser.......................... : yes > build from version............ : release > glpk............................. : no > gmv.............................. : yes > gzstream......................... : yes > laspack.......................... : yes > libhilbert....................... : yes > metis............................ : yes > mpi.............................. : yes > nemesis.......................... : yes > netcdf........................... : yes > openmp........................... : yes > parmetis......................... : yes > petsc............................ : yes > version....................... : 3.2.0 > sfcurves......................... : yes > slepc............................ : no > tbb.............................. : no > c++ threads...................... : no > tecio............................ : no > tecplot...(vendor binaries)...... : yes > tetgen........................... : yes > triangle......................... : yes > trilinos......................... : yes > AztecOO....................... : no > NOX........................... : no > ML............................ : no > vtk.............................. : yes > > libmesh_optional_INCLUDES........ : -I/home/xxxx/opt/include/vtk-5.6 -I/home/xxxx/opt/build/petsc-3.2-p6/include -I/home/xxxx/opt/build/petsc-3.2-p6/linux-gnu-opt/include -I/usr/include > > libmesh_optional_LIBS............ : -Wl,-rpath,/home/xxxx/opt/lib/vtk-5.6 -L/home/xxxx/opt/lib/vtk-5.6 -lvtkIO -lvtkCommon -lvtkFiltering -lz -L/home/xxxx/opt/build/petsc-3.2-p6/linux-gnu-opt/lib -lpetsc -lX11 -Wl,-rpath,/home/xxxx/opt/build/petsc-3.2-p6/linux-gnu-opt/lib -lcmumps -ldmumps -lsmumps -lzmumps -lmumps_common -lpord -lparmetis -lmetis -lsuperlu_4.2 -lscalapack -lblacs -lflapack -lfblas -L/usr/lib64/gcc/x86_64-suse-linux/4.5 -L/global/linux/64_bit/opt/intel/mkl/10.2.2.025/lib/em64t -L/global/linux/64_bit/opt/intel/mkl/10.2.2.025/lib/32 -L/global/linux/64_bit/opt/intel/mkl/10.2.2.025/lib/64 -L/usr/x86_64-suse-linux/lib -lmpichf90 -lgfortran -lm -lmpich -lopa -lmpl -lrt -lpthread -lgcc_s -ldl > > ------------------------------------------------------------------------------- > Configure complete, now type 'make' and then 'make install'. > > --------------------------------------------- > --------- Done Configuring libMesh ---------- > --------------------------------------------- > > <config.log> |
From: Robert <li...@ro...> - 2012-11-19 16:07:56
|
Hi Ben, I am using the mpi installation provided by PetSc with --download-mpich=1. So the mpi used should be the one in ~/opt/build/petsc-3.2-p6/linux-gnu-opt/include Robert On Mon, Nov 19, 2012 at 09:28:22AM -0600, Kirk, Benjamin (JSC-EG311) wrote: > Very good, thanks. Where on your system is MPI actually installed? > > The issue is that the Parmetis makefile is not inheriting every -I…. that libMesh is using, which is actually the way I want it. In particular, it is not getting all of libmesh_optional_INCLUDES > > But the only thing I suspect there is that your MPI lives in /usr/include, which should not *need* to be specified. > > Thanks, > > -Ben > > > > On Nov 19, 2012, at 9:14 AM, Robert <li...@ro...> wrote: > > > > > > > On Mon, Nov 19, 2012 at 08:43:52AM -0600, Kirk, Benjamin (JSC-EG311) wrote: > >> > >> On Nov 19, 2012, at 8:39 AM, Robert <li...@ro...> wrote: > >> > >>> My older installation of libmesh (r5498) works fine on the same computer with MPI. Even with > >>> "make V=0" I could not get more information about the compilerflags used, so I cannot really > >>> figure out, if it is a problem on my side or the build-system. > >> > >> > >> Well the problem is that the MPI configuration is not being determined properly, but the question is why. Can you post the summary information from configure (where it prints all that) and also send me your config.log? > >> > >> configure should still be looking preferentially for the MPI compilers and then falling back to snooping the MPI configuration from PETSc, so this should be a straightforward fix. > >> > > > > > > The configure summary is pasted below and the config.log is attached > > > > ----------------------------------- SUMMARY ----------------------------------- > > > > Package version.................... : libmesh-0.9.0 > > > > C++ compiler type.................. : gcc4.5 > > C++ compiler....................... : g++ > > C compiler......................... : gcc > > Fortran compiler................... : gfortran > > Build Method....................... : opt > > CPPFLAGS........................... : -DNDEBUG > > CXXFLAGS........................... : -O2 -felide-constructors -funroll-loops -fstrict-aliasing -std=c++0x -Wdisabled-optimization -fopenmp > > CFLAGS............................. : -O2 -funroll-loops -fstrict-aliasing -fopenmp > > Install dir........................ : /tmp/libmesh > > Build user......................... : xxxx > > Build host......................... : stokes > > Configure date..................... : 2012-11-19 15:26 > > Build architecture................. : x86_64-unknown-linux-gnu > > SVN revision number................ : 6404 > > > > Library Features: > > adaptive mesh refinement......... : yes > > complex variables................ : no > > ghosted vectors.................. : yes > > high-order shape functions....... : yes > > infinite elements................ : no > > Dirichlet constraints............ : yes > > node constraints................. : no > > parallel mesh.................... : no > > performance logging.............. : no > > periodic boundary conditions..... : yes > > reference counting............... : yes > > shape function 2nd derivatives... : yes > > stack trace files................ : no > > subdomain id size................ : 2 bytes > > variational smoother............. : yes > > xdr binary I/O................... : yes > > > > Optional Packages: > > boost............................ : yes > > eigen............................ : no > > exodus........................... : yes > > fparser.......................... : yes > > build from version............ : release > > glpk............................. : no > > gmv.............................. : yes > > gzstream......................... : yes > > laspack.......................... : yes > > libhilbert....................... : yes > > metis............................ : yes > > mpi.............................. : yes > > nemesis.......................... : yes > > netcdf........................... : yes > > openmp........................... : yes > > parmetis......................... : yes > > petsc............................ : yes > > version....................... : 3.2.0 > > sfcurves......................... : yes > > slepc............................ : no > > tbb.............................. : no > > c++ threads...................... : no > > tecio............................ : no > > tecplot...(vendor binaries)...... : yes > > tetgen........................... : yes > > triangle......................... : yes > > trilinos......................... : yes > > AztecOO....................... : no > > NOX........................... : no > > ML............................ : no > > vtk.............................. : yes > > > > libmesh_optional_INCLUDES........ : -I/home/xxxx/opt/include/vtk-5.6 -I/home/xxxx/opt/build/petsc-3.2-p6/include -I/home/xxxx/opt/build/petsc-3.2-p6/linux-gnu-opt/include -I/usr/include > > > > libmesh_optional_LIBS............ : -Wl,-rpath,/home/xxxx/opt/lib/vtk-5.6 -L/home/xxxx/opt/lib/vtk-5.6 -lvtkIO -lvtkCommon -lvtkFiltering -lz -L/home/xxxx/opt/build/petsc-3.2-p6/linux-gnu-opt/lib -lpetsc -lX11 -Wl,-rpath,/home/xxxx/opt/build/petsc-3.2-p6/linux-gnu-opt/lib -lcmumps -ldmumps -lsmumps -lzmumps -lmumps_common -lpord -lparmetis -lmetis -lsuperlu_4.2 -lscalapack -lblacs -lflapack -lfblas -L/usr/lib64/gcc/x86_64-suse-linux/4.5 -L/global/linux/64_bit/opt/intel/mkl/10.2.2.025/lib/em64t -L/global/linux/64_bit/opt/intel/mkl/10.2.2.025/lib/32 -L/global/linux/64_bit/opt/intel/mkl/10.2.2.025/lib/64 -L/usr/x86_64-suse-linux/lib -lmpichf90 -lgfortran -lm -lmpich -lopa -lmpl -lrt -lpthread -lgcc_s -ldl > > > > ------------------------------------------------------------------------------- > > Configure complete, now type 'make' and then 'make install'. > > > > --------------------------------------------- > > --------- Done Configuring libMesh ---------- > > --------------------------------------------- > > > > <config.log> > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-19 16:20:28
|
On Nov 19, 2012, at 10:07 AM, Robert <li...@ro...> wrote: > Hi Ben, > > I am using the mpi installation provided by PetSc with > --download-mpich=1. So the mpi used should be the one in > ~/opt/build/petsc-3.2-p6/linux-gnu-opt/include OK, I'll see about building PETSC like this and update the configure script to pass parmetis (nemesis) the relevant MPI configuration info from the build-in petsc flavor. In the meantime, you should be able to complete the build with --disable-parmetis --disable-nemesis -Ben |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-19 16:33:51
|
Make that --disable-parmetis - Looks like nemesis does not actually use MPI?! -Ben On Nov 19, 2012, at 10:20 AM, "Kirk, Benjamin (JSC-EG311)" <ben...@na...> wrote: > On Nov 19, 2012, at 10:07 AM, Robert <li...@ro...> wrote: > >> Hi Ben, >> >> I am using the mpi installation provided by PetSc with >> --download-mpich=1. So the mpi used should be the one in >> ~/opt/build/petsc-3.2-p6/linux-gnu-opt/include > > OK, I'll see about building PETSC like this and update the configure script to pass parmetis (nemesis) the relevant MPI configuration info from the build-in petsc flavor. > > In the meantime, you should be able to complete the build with --disable-parmetis --disable-nemesis > > -Ben > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-16 20:29:17
|
Actually looks like I have some free time now - anything else in the pipeline? -Ben On Nov 16, 2012, at 12:37 PM, "Kirk, Benjamin (JSC-EG311)" <ben...@na...> wrote: > Thanks. I won't do this until the evening at the earliest. > > -Ben > > > > On Nov 16, 2012, at 12:17 PM, "Roy Stogner" <roy...@ic...> wrote: > >> On Fri, 16 Nov 2012, Roy Stogner wrote: >> >>>> There might be another ParallelMesh-with-repartitioning fix coming >>>> soon, but nothing from me that should prevent the fork / merge. >> >> Actually, I'll have a few Cygwin fixes coming in too. I'll check for >> branched-out-from-under-me before committing them, though. >> --- >> Roy >> >> ------------------------------------------------------------------------------ >> Monitor your physical, virtual and cloud infrastructure from a single >> web console. Get in-depth insight into apps, servers, databases, vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications! >> http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2012-11-16 21:08:52
|
On Fri, 16 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote: > Actually looks like I have some free time now - anything else in the pipeline? Hmmm... the remaining steps to get Cygwin working (new versions of Cygwin, anyway - their shared library conventions seem to have changed slightly in the last several years and yanked the .so rug out from under us) are going to make me futz with the build system, so I'd be content to just drop the idea for 0.8.0 and save Cygwin support for the autotools release. Go ahead with the swap, then. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-16 21:10:49
|
OK. doing it now, will send a summary email describing the changes within the hour. -Ben On Nov 16, 2012, at 3:08 PM, Roy Stogner <roy...@ic...> wrote: > > On Fri, 16 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote: > >> Actually looks like I have some free time now - anything else in the pipeline? > > Hmmm... the remaining steps to get Cygwin working (new versions of > Cygwin, anyway - their shared library conventions seem to have changed > slightly in the last several years and yanked the .so rug out from > under us) are going to make me futz with the build system, so I'd be > content to just drop the idea for 0.8.0 and save Cygwin support for > the autotools release. > > Go ahead with the swap, then. > --- > Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-16 21:40:51
|
As of r6384, I am merging the automake branch back in to trunk. The old build system (trunk at r6383) exists as https://libmesh.svn.sourceforge.net/svnroot/libmesh/branches/libmesh-0.8.0 Unfortunately, the underlying SVN database on sourceforge is old and crusty, so am having to do some svnadmin hackery to update it to a recent format so I can reintegrate. I will send another email when this completes and trunk is back in business. Thanks, -Ben |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-19 16:43:32
|
On Nov 19, 2012, at 10:07 AM, Robert <li...@ro...> wrote: > Hi Ben, > > I am using the mpi installation provided by PetSc with > --download-mpich=1. So the mpi used should be the one in > ~/opt/build/petsc-3.2-p6/linux-gnu-opt/include r6407 should pass PETSc's include paths to parmetis, which should resolve your issue. Thanks, -Ben |
From: Robert <li...@ro...> - 2012-11-20 16:05:07
|
Hello, yes that works. But I have discovered some other issues: - The installed libmesh-config script does not work, if it is called using a relative file path. Removing "$script_path" from line 37 fixes this. - In my opinion the installed stuff should follow somehow the FHS, so there are no problems using prefix=/usr/local or even prefix=/ (as packagers for e.g. Debian would do). - When using the default configuration the libmesh shared library is build against openmp. When using the pkg-config files to integrate libmesh into my application the link process fails with: /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `GOMP_parallel_start' /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `GOMP_single_start' /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `GOMP_barrier' /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `omp_get_thread_num' /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `GOMP_parallel_end' /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `omp_get_num_threads' collect2: ld returned 1 exit status so there is a linker flag missing at least in the pkg-config file And one last thing: Does any know a possiblity to use the pkg-config version selector to switch between dbg and opt builds? Robert On Mon, Nov 19, 2012 at 10:43:20AM -0600, Kirk, Benjamin (JSC-EG311) wrote: > On Nov 19, 2012, at 10:07 AM, Robert <li...@ro...> wrote: > > > Hi Ben, > > > > I am using the mpi installation provided by PetSc with > > --download-mpich=1. So the mpi used should be the one in > > ~/opt/build/petsc-3.2-p6/linux-gnu-opt/include > > r6407 should pass PETSc's include paths to parmetis, which should resolve your issue. > > Thanks, > > -Ben > > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-20 16:38:49
|
On Nov 20, 2012, at 10:04 AM, Robert <li...@ro...> wrote: > Hello, > > yes that works. But I have discovered some other issues: > - The installed libmesh-config script does not work, if it is called using > a relative file path. Removing "$script_path" from line 37 fixes this. > - In my opinion the installed stuff should follow somehow the FHS, so > there are no problems using prefix=/usr/local or even prefix=/ (as > packagers for e.g. Debian would do). Good input, I'll review the latest FHS document - what in particular stands out as needing to be changed? > - When using the default configuration the libmesh shared library is > build against openmp. When using the pkg-config files to integrate > libmesh into my application the link process fails with: > > /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `GOMP_parallel_start' > /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `GOMP_single_start' > /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `GOMP_barrier' > /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `omp_get_thread_num' > /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `GOMP_parallel_end' > /tmp/libmesh/lib/x86_64-suse-linux-gnu_opt/libmesh.so: undefined reference to `omp_get_num_threads' > collect2: ld returned 1 exit status > > so there is a linker flag missing at least in the pkg-config file Looks like the OpenMP configuration is not making it in there - I'll fix it. Sorry, I've primarily been using the libmesh-config script. > And one last thing: Does any know a possiblity to use the pkg-config > version selector to switch between dbg and opt builds? > As implemented now, no. There is a libmesh.pc per method, and they get installed inside the lib directory for that method. I could refactor it to use e.g. $ pkg-config libmesh --define-variable=METHOD=dbg and default to opt - would that be preferable? -Ben |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-17 03:18:39
|
Merge is complete and trunk is back in business. I'll be working on updating documentation for updating the build system over the next few days. In the meantime please contact me before you get too frustrated with automake - it is usually easy to do something if you do it the 'automake way.' -Ben On Nov 16, 2012, at 3:40 PM, "Kirk, Benjamin (JSC-EG311)" <ben...@na...> wrote: > As of r6384, I am merging the automake branch back in to trunk. > > The old build system (trunk at r6383) exists as > > https://libmesh.svn.sourceforge.net/svnroot/libmesh/branches/libmesh-0.8.0 > > Unfortunately, the underlying SVN database on sourceforge is old and crusty, so am having to do some svnadmin hackery to update it to a recent format so I can reintegrate. I will send another email when this completes and trunk is back in business. > > Thanks, > > -Ben > > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Derek G. <fri...@gm...> - 2012-11-17 04:57:00
|
So, did we decide we were going to check in "configure" or what? Here's what happens with bootstrap on my Lion MacBook Pro: autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I m4 configure.ac:56: error: Autoconf version 2.62 or higher is required m4/prefix_config.m4:209: AX_PREFIX_CONFIG_H is expanded from... configure.ac:56: the top level autom4te: /usr/bin/gm4 failed with exit status: 63 aclocal: /usr/bin/autom4te failed with exit status: 63 autoreconf: aclocal failed with exit status: 63 On Fri, Nov 16, 2012 at 9:18 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > Merge is complete and trunk is back in business. I'll be working on > updating documentation for updating the build system over the next few days. > > In the meantime please contact me before you get too frustrated with > automake - it is usually easy to do something if you do it the 'automake > way.' > > -Ben > > > > On Nov 16, 2012, at 3:40 PM, "Kirk, Benjamin (JSC-EG311)" < > ben...@na...> wrote: > > > As of r6384, I am merging the automake branch back in to trunk. > > > > The old build system (trunk at r6383) exists as > > > > > https://libmesh.svn.sourceforge.net/svnroot/libmesh/branches/libmesh-0.8.0 > > > > Unfortunately, the underlying SVN database on sourceforge is old and > crusty, so am having to do some svnadmin hackery to update it to a recent > format so I can reintegrate. I will send another email when this completes > and trunk is back in business. > > > > Thanks, > > > > -Ben > > > > > > > > > ------------------------------------------------------------------------------ > > Monitor your physical, virtual and cloud infrastructure from a single > > web console. Get in-depth insight into apps, servers, databases, vmware, > > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > > Pricing starts from $795 for 25 servers or applications! > > http://p.sf.net/sfu/zoho_dev2dev_nov > > _______________________________________________ > > Libmesh-devel mailing list > > Lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-17 12:49:14
|
What Id like to try first is beefing up bootstrap to install the newer versions for you. It does that now if the autotools are missing, so it just needs to be updated to go the version checking too. I'll get to that after kids soccer today. In the meantime you can cut and paste the relevant lines from bootstrap and it will install a local set of the autotools in your development tree. -Ben On Nov 16, 2012, at 10:56 PM, "Derek Gaston" <fri...@gm...<mailto:fri...@gm...>> wrote: So, did we decide we were going to check in "configure" or what? Here's what happens with bootstrap on my Lion MacBook Pro: autoreconf: Entering directory `.' autoreconf: configure.ac<http://configure.ac>: not using Gettext autoreconf: running: aclocal -I m4 configure.ac:56<http://configure.ac:56>: error: Autoconf version 2.62 or higher is required m4/prefix_config.m4:209: AX_PREFIX_CONFIG_H is expanded from... configure.ac:56<http://configure.ac:56>: the top level autom4te: /usr/bin/gm4 failed with exit status: 63 aclocal: /usr/bin/autom4te failed with exit status: 63 autoreconf: aclocal failed with exit status: 63 On Fri, Nov 16, 2012 at 9:18 PM, Kirk, Benjamin (JSC-EG311) <ben...@na...<mailto:ben...@na...>> wrote: Merge is complete and trunk is back in business. I'll be working on updating documentation for updating the build system over the next few days. In the meantime please contact me before you get too frustrated with automake - it is usually easy to do something if you do it the 'automake way.' -Ben On Nov 16, 2012, at 3:40 PM, "Kirk, Benjamin (JSC-EG311)" <ben...@na...<mailto:ben...@na...>> wrote: > As of r6384, I am merging the automake branch back in to trunk. > > The old build system (trunk at r6383) exists as > > https://libmesh.svn.sourceforge.net/svnroot/libmesh/branches/libmesh-0.8.0 > > Unfortunately, the underlying SVN database on sourceforge is old and crusty, so am having to do some svnadmin hackery to update it to a recent format so I can reintegrate. I will send another email when this completes and trunk is back in business. > > Thanks, > > -Ben > > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Libmesh-devel mailing list > Lib...@li...<mailto:Lib...@li...> > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Libmesh-devel mailing list Lib...@li...<mailto:Lib...@li...> https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Derek G. <fri...@gm...> - 2012-11-17 17:20:08
|
Ok - so I know we've had a bit of back and forth over this issue. So I'm only going to argue for configure in the repo one more time. Here is my argument: It's what users expect. When I checkout a repo I always expect to be able to do: ./configure make make install (optionally) I thought that one of the reasons we were moving to Automake was to get closer to what users expect (in the "make install" arena). Further, libMesh has always been usable through a simple: ./configure make So it's what _our_ users expect. There was some back and forth about whether or not we needed "configure" in the repo or only in our distributed tarballs. Here are my thoughts: 1. Most people using libMesh use the repo... and it's something we actively encourage. It should work just like a release. 2. A lot of projects put configure in the repo. To show #2, here is a list of free software on Savannah ( http://savannah.gnu.org/ ) the GNU software repository that both has configure in the repo (just random clicking around, there is a bunch of junk in there): ACM: http://cvs.savannah.gnu.org/viewvc/acm/acm/ Combine: http://cvs.savannah.gnu.org/viewvc/combine/combine/ Crust: http://cvs.savannah.gnu.org/viewvc/crust/crust/ Emacs: http://cvs.savannah.gnu.org/viewvc/emacs/emacs/ Epiwm: http://cvs.savannah.gnu.org/viewvc/epiwm/epiwm/ Grub: http://cvs.savannah.gnu.org/viewvc/grub/grub2/ (got tired of looking through crappy projects) There are definitely a lot of projects that don't put configure in the repo as well... BUT I believe that since our users mainly use our repo version (which is not the norm for a lot of software) our repo should come in a form that is amenable to our users. Finally... one last thing: libMesh needs to be able to compile on MANY different kinds of machines. This is unique to HPC software like this. We have to have it "just work" on all kinds of crazy architectures that we have no control over. For that reason, I think that we shouldn't rely on Autoconf on those machines... and should have a checked in version of configure that we know is good. Ok - I've said my peace. Derek On Sat, Nov 17, 2012 at 6:49 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > What Id like to try first is beefing up bootstrap to install the newer > versions for you. It does that now if the autotools are missing, so it just > needs to be updated to go the version checking too. > > I'll get to that after kids soccer today. In the meantime you can cut and > paste the relevant lines from bootstrap and it will install a local set of > the autotools in your development tree. > > -Ben > > > On Nov 16, 2012, at 10:56 PM, "Derek Gaston" <fri...@gm...> wrote: > > So, did we decide we were going to check in "configure" or what? > > Here's what happens with bootstrap on my Lion MacBook Pro: > > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal -I m4 > configure.ac:56: error: Autoconf version 2.62 or higher is required > m4/prefix_config.m4:209: AX_PREFIX_CONFIG_H is expanded from... > configure.ac:56: the top level > autom4te: /usr/bin/gm4 failed with exit status: 63 > aclocal: /usr/bin/autom4te failed with exit status: 63 > autoreconf: aclocal failed with exit status: 63 > > > > > On Fri, Nov 16, 2012 at 9:18 PM, Kirk, Benjamin (JSC-EG311) < > ben...@na...> wrote: > >> Merge is complete and trunk is back in business. I'll be working on >> updating documentation for updating the build system over the next few days. >> >> In the meantime please contact me before you get too frustrated with >> automake - it is usually easy to do something if you do it the 'automake >> way.' >> >> -Ben >> >> >> >> On Nov 16, 2012, at 3:40 PM, "Kirk, Benjamin (JSC-EG311)" < >> ben...@na...> wrote: >> >> > As of r6384, I am merging the automake branch back in to trunk. >> > >> > The old build system (trunk at r6383) exists as >> > >> > >> https://libmesh.svn.sourceforge.net/svnroot/libmesh/branches/libmesh-0.8.0 >> > >> > Unfortunately, the underlying SVN database on sourceforge is old and >> crusty, so am having to do some svnadmin hackery to update it to a recent >> format so I can reintegrate. I will send another email when this completes >> and trunk is back in business. >> > >> > Thanks, >> > >> > -Ben >> > >> > >> > >> > >> ------------------------------------------------------------------------------ >> > Monitor your physical, virtual and cloud infrastructure from a single >> > web console. Get in-depth insight into apps, servers, databases, vmware, >> > SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> > Pricing starts from $795 for 25 servers or applications! >> > http://p.sf.net/sfu/zoho_dev2dev_nov >> > _______________________________________________ >> > Libmesh-devel mailing list >> > Lib...@li... >> > https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> >> >> >> ------------------------------------------------------------------------------ >> Monitor your physical, virtual and cloud infrastructure from a single >> web console. Get in-depth insight into apps, servers, databases, vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications! >> http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> > > |
From: Roy S. <roy...@ic...> - 2012-11-17 17:42:32
|
On Sat, 17 Nov 2012, Derek Gaston wrote: > So I'm only going to argue for configure in the repo one more time. For what it's worth, I generally *despise* putting intermediate, generated files in svn repositories. The PECOS svn tree log is littered with entries that are nothing more than roystgnr is svn removing other users' regeneratable files the way Rain Man picks up toothpicks. I count configure in the "stuff to get out of the repo" category, in an environment like PECOS where professional IT people (or Paul or me, at least) are making sure that everyone has access to a tested recent autotools version. But in a publically-available project? Let's make an exception. Until we start auto-tarring nightly releases or doing something similar to give users a minimal-dependencies way to build a recent libMesh, let's leave a pre-built configure in svn. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-17 18:23:23
|
I'm updating bootstrap now, if we are going to check in generated files I'm going to be really pedantic about only allowing one to generate a file with the newest version of everything. Then I'll add the generated files. -Ben On Nov 17, 2012, at 11:42 AM, "Roy Stogner" <roy...@ic...> wrote: > > On Sat, 17 Nov 2012, Derek Gaston wrote: > >> So I'm only going to argue for configure in the repo one more time. > > For what it's worth, I generally *despise* putting intermediate, > generated files in svn repositories. The PECOS svn tree log is > littered with entries that are nothing more than roystgnr is svn > removing other users' regeneratable files the way Rain Man picks up > toothpicks. > > I count configure in the "stuff to get out of the repo" category, in > an environment like PECOS where professional IT people (or Paul or me, > at least) are making sure that everyone has access to a tested recent > autotools version. > > But in a publically-available project? Let's make an exception. > > Until we start auto-tarring nightly releases or doing something > similar to give users a minimal-dependencies way to build a recent > libMesh, let's leave a pre-built configure in svn. > --- > Roy |
From: Derek G. <fri...@gm...> - 2012-11-17 19:17:51
|
Sounds good Ben! We'll see how this evolves over time. If it's a problem having it in the repo we can remove it later. Derek Sent from my iPhone On Nov 17, 2012, at 11:23 AM, "Kirk, Benjamin (JSC-EG311)" <ben...@na...> wrote: > I'm updating bootstrap now, if we are going to check in generated files I'm going to be really pedantic about only allowing one to generate a file with the newest version of everything. > > Then I'll add the generated files. > > -Ben > > > > > On Nov 17, 2012, at 11:42 AM, "Roy Stogner" <roy...@ic...> wrote: > >> >> On Sat, 17 Nov 2012, Derek Gaston wrote: >> >>> So I'm only going to argue for configure in the repo one more time. >> >> For what it's worth, I generally *despise* putting intermediate, >> generated files in svn repositories. The PECOS svn tree log is >> littered with entries that are nothing more than roystgnr is svn >> removing other users' regeneratable files the way Rain Man picks up >> toothpicks. >> >> I count configure in the "stuff to get out of the repo" category, in >> an environment like PECOS where professional IT people (or Paul or me, >> at least) are making sure that everyone has access to a tested recent >> autotools version. >> >> But in a publically-available project? Let's make an exception. >> >> Until we start auto-tarring nightly releases or doing something >> similar to give users a minimal-dependencies way to build a recent >> libMesh, let's leave a pre-built configure in svn. >> --- >> Roy |
From: Derek G. <fri...@gm...> - 2012-11-17 21:23:29
|
I just tried out the configure that is checked in... and everything seemed to go well. However, a "make" produces: CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /Users/gastdr/projects/libmesh/build-aux/missing --run aclocal-1.12 -I m4 /Users/gastdr/projects/libmesh/build-aux/missing: line 51: aclocal-1.12: command not found WARNING: 'aclocal-1.12' is missing on your system. You should only need it if you modified 'acinclude.m4' or 'configure.ac'. You might want to install the Automake and Perl packages. Grab them from any GNU archive site. CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /Users/gastdr/projects/libmesh/build-aux/missing --run autoconf configure.ac:59: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:71: error: possibly undefined macro: AM_CONDITIONAL make: *** [configure] Error 1 On Sat, Nov 17, 2012 at 1:17 PM, Derek Gaston <fri...@gm...> wrote: > Sounds good Ben! > > We'll see how this evolves over time. If it's a problem having it in > the repo we can remove it later. > > Derek > > Sent from my iPhone > > On Nov 17, 2012, at 11:23 AM, "Kirk, Benjamin (JSC-EG311)" > <ben...@na...> wrote: > > > I'm updating bootstrap now, if we are going to check in generated files > I'm going to be really pedantic about only allowing one to generate a file > with the newest version of everything. > > > > Then I'll add the generated files. > > > > -Ben > > > > > > > > > > On Nov 17, 2012, at 11:42 AM, "Roy Stogner" <roy...@ic...> > wrote: > > > >> > >> On Sat, 17 Nov 2012, Derek Gaston wrote: > >> > >>> So I'm only going to argue for configure in the repo one more time. > >> > >> For what it's worth, I generally *despise* putting intermediate, > >> generated files in svn repositories. The PECOS svn tree log is > >> littered with entries that are nothing more than roystgnr is svn > >> removing other users' regeneratable files the way Rain Man picks up > >> toothpicks. > >> > >> I count configure in the "stuff to get out of the repo" category, in > >> an environment like PECOS where professional IT people (or Paul or me, > >> at least) are making sure that everyone has access to a tested recent > >> autotools version. > >> > >> But in a publically-available project? Let's make an exception. > >> > >> Until we start auto-tarring nightly releases or doing something > >> similar to give users a minimal-dependencies way to build a recent > >> libMesh, let's leave a pre-built configure in svn. > >> --- > >> Roy > |