On Wed, Sep 8, 2010 at 11:28 PM, Paul Barbone <[email protected]> wrote: > On 9/8/10 4:06 PM, Anders Logg wrote: >> >> On Wed, Sep 08, 2010 at 04:01:12PM -0400, Paul Barbone wrote: >>> >>> On 9/8/10 2:58 PM, Anders Logg wrote: >>>> >>>> On Wed, Sep 08, 2010 at 02:49:01PM -0400, Paul Barbone wrote: >>>>> >>>>> On 9/7/10 2:15 AM, Anders Logg wrote: >>>>>> >>>>>> On Mon, Sep 06, 2010 at 07:14:21PM -0400, Paul Barbone wrote: >>>>>>> >>>>>>> On 9/6/10 6:32 PM, Anders Logg wrote: >>>>>>>> >>>>>>>> Did you install PETSc and SLEPc yourself or did you let Dorsal build >>>>>>>> them? >>>>>>> >>>>>>> I let dorsal build them. >>>>>>>> >>>>>>>> Did you have any old versions of any of the libraries on your >>>>>>>> system? >>>>>>> >>>>>>> Yes, but these were in different directories, and incidentally >>>>>>> installed from an older dorsal build. I tried to keep things >>>>>>> separate, but there is some overlap between the installations. >>>>>>> They use the same python, for example, but the PETSc and SLEPc are >>>>>>> distinct. >>>>>> >>>>>> Could you try locating all those libraries and (at least temporarily) >>>>>> rename or move them to a location where they can't be found? >>>>>> >>>>>> Then clean out the Dorsal build and start with a clean installation. >>>>>> >>>>>> Our scripts should be able to find the correct versions but the >>>>>> configure scripts need some more work. >>>>>> >>>>> Ok. I reinstalled python, etc, via macports, deleted the old FEniCS >>>>> directory, and installed completely new. I eventually got precisely >>>>> the same behavior. >>>> >>>> Very strange. It works fine on my Snow Leopard (including SCOTCH). I >>>> haven't done anything special. Your hope is that either someone else >>>> has the same problem and knows how to fix it, or you find out what the >>>> problem is yourself. >>>> >>>> It is not that difficult to add some debugging to the DOLFIN CMake >>>> configure scripts. They are located in the cmake/modules/ directory >>>> and named FindPETSc.cmake etc. Let us what you find out. >>>> >>> Thanks. That's helpful. Where is PETSC_ARCH specified? It changes >>> from its definition in the foo.platform file. >> >> It shouldn't be changed by Dorsal anywhere along the way. There is >> some code in FindPETSc.cmake that tries to figure out PETSC_DIR. Look >> for this passage: >> >> # Try to figure out PETSC_ARCH if not set >> if (PETSC_DIR AND NOT PETSC_ARCH) >> >> You can start by printing out the value of PETSC_ARCH prior to this >> and see if it looks ok: >> >> message("DEBUG PETSC_ARCH = ${PETSC_ARCH}") >> >> -- >> Anders > > It gives PETSC_ARCH=darwin10.0.0-cxx-opt at this point, regardless of what > this variable is set to in the *.platform file. In my older installation, > this variable was darwin9.2.0... This is a difference, but I doubt, > frankly, that it's important. > > What I really don't understand and what I think is important is this: > > Linking CXX shared library libdolfin.dylib > Undefined symbols: > "_METIS_mCPartGraphRecursive2", referenced from: > _ParMETIS_V3_PartKway in libparmetis.a(kmetis.o) > _PartitionSmallGraph__ in libparmetis.a(weird.o) > _Mc_InitPartition_RB__ in libparmetis.a(initpart.o) > _Mc_InitPartition_RB__ in libparmetis.a(initpart.o) > _Balance_Partition__ in libparmetis.a(initbalance.o) > _Balance_Partition__ in libparmetis.a(initbalance.o) > ld: symbol(s) not found > collect2: ld returned 1 exit status > > This is extracted from the dolfin build_log file, and also prints to the > screen just before death.
The problem is probably that DOLFIN picks up the METIS library that comes with MacPorts (/opt/local/lib/libmetis.dylib) instead of the one from ParMETIS that Dorsal installs and PETSc is built with ($INSTALL_PATH/lib/libmetis.a). I have solved this on the buildbot by specifying -DMETIS_LIBRARY=$INSTALL_PATH/lib/libmetis.a when configuring DOLFIN. Johannes _______________________________________________ Mailing list: https://launchpad.net/~dorsal Post to : [email protected] Unsubscribe : https://launchpad.net/~dorsal More help : https://help.launchpad.net/ListHelp
