On 3/3/11 10:44 AM, Roy Stogner wrote: > > On Thu, 3 Mar 2011, John Peterson wrote: > >> I confess that even with dbg builds of libmesh, I use the optimized >> PETSc libraries... therefore the PETSC_ARCH and PETSC_DIR that gets >> set at configure time is truly constant in my builds. One reason for >> this is that even optimized PETSc builds have some debugging >> information available in them... Another is that dbg petsc builds can >> run significantly slower, and you aren't really debugging petsc after >> all (I hope) but the inputs to it from libmesh. > > This is how I operate, and mostly for the same reasons. > > But the main reason I never even considered switching on the fly > between different underlying PETSc builds is that I didn't know for > sure it was *possible*. With libMesh our debug mode isn't > ABI-compatible with our opt mode (due to the glibcxx debug STL stuff), > and I bet there are lots configure-time options that have similar > effects due to structure packing changes, linking dependency changes, > etc. I didn't want to bother finding out whether PETSc had any > similar "gotchas" between different configurations.
I think that the answer is: "it depends". If you configure different PETSC_ARCH'es with configure/compiler flags that yield ABI-incompatible libraries, then you, ummmmm, get ABI-incompatible libraries. :-) Personally, what I do is to keep separate libMesh directories with builds that correspond to different PETSC_ARCH'es --- generally one opt and one debug. Because I think it is in general hard to detect robustly whether you can "safely" switch between PETSC_ARCH'es without doing a full recompilation, a nice compromise might be to be able to associate different PETSC_DIR/PETSC_ARCH values with different libMesh build modes. At least, this a feature that I would use. -- Boyce ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
