From: Roy S. <roy...@ic...> - 2007-12-03 20:11:23
|
I wrote the following to Ben and John when I was just concerned about seeing if we needed to update our Wiki instructions for the lonestar supercomputer, but I'm starting to think we might be able to use a more general fix in the library: On Mon, 3 Dec 2007, Roy Stogner wrote: > I'm getting undefined references to PETSc dependencies whenever I try > to link the libmesh examples, e.g.: > > /opt/apps/petsc-intel9-2.3.3/2.3.3/lib/em64t/libpetscksp.a(ml.o): In > function `PCSetUp_ML': > (.text+0x1de): undefined reference to `ML_Destroy' > > /opt/apps/petsc-intel9-2.3.3/2.3.3/lib/em64t/libpetscmat.a(chaco.o): > In function `MatPartitioningApply_Chaco': > (.text+0x14): undefined reference to `FREE_GRAPH' > > /opt/apps/petsc-intel9-2.3.3/2.3.3/lib/em64t/libpetscmat.a(mumps.o): > In function `MatDestroy_MUMPS': > (.text+0x137): undefined reference to `dmumps_c' > > ML, Chaco, and Mumps seem to be built in > /opt/apps/petsc-intel9-2.3.3/2.3.3/externalpackages/, and I guess I > can hunt down the right -L/-l options to add to my Make.common by > hand, but I thought our config scripts were supposed to be snooping > PETSc's configuration somehow to set up the necessary linker options. What's going on is that we're snooping PETSc's configuration for a bunch of individual library options: $(SUPERLU_DIST_LIB), $(BLOPEX_LIB), etc, and we're including those options in our Make.common. Instead of trying to include every dependency one at a time, shouldn't we be getting PETSc's whole list and using that? What worked for me on lonestar was to change this: libmesh_LIBS += $(libs-PETSC) \ $(BLOCKSOLVE_LIB) $(SPOOLES_LIB) $(HYPRE_LIB) \ $(SUPERLU_DIST_LIB) $(UMFPACK_LIB) $(SUPERLU_LIB) \ $(BLOPEX_LIB) $(SPAI_LIB) \ $(BLASLAPACK_LIB) $(X11_LIB) $(MATLAB_LIB) \ $(libmesh_FLIBS) Into this: libmesh_LIBS += $(libs-PETSC) \ $(PACKAGES_LIBS) \ $(libmesh_FLIBS) It's a lot simpler, but more importantly I *think* it's more robust. Unless someone screams that I'm going to break their build, I'll probably check the corresponding changes to Make.common.in into subversion soon. --- Roy |