On Thu, Apr 26, 2012 at 3:57 PM, Roy Stogner <firstname.lastname@example.org>
On Thu, 26 Apr 2012, Kirk, Benjamin (JSC-EG311) wrote:
>>> C-style? For background, David is having a parmetis version clash betweenMy thoughts exactly.
>>> ours and the one included in petsc-dev with sieve enabled.
>> This would work fine to avoid compile-time ambiguity, but there will
>> still be multiple versions of the same functions floating around at
>> link time, won't there? On some systems if the versions are ABI
>> compatible that will work, but any ABI incompatibility may cause nasty
>> breakage, and IIRC some systems' linkers will just scream and die when
>> they see two definitions of the same symbol.
>> Not sure what can be done about this with C libraries. In the "PETSc
>> links one version, Trilinos links another" case it would be pretty
>> much out of our hands, no?
> An easy fix for the things we insist on building from source would be to
> compile them with c++ instead of C - I'd think the name mangling would
> differentiate the ABI from its C counterpart. Of course if you used C++ to
> build PETSc it may still pop up there.
> We could also put them in a namespace then but that sounds way intrusive.
Right - unless the default PETSc install already leaves parmetis
>> I still think the best solution is to allow our contrib libraries to
>> be replaced at configure time by system libraries, and then if your
>> system libraries include mutually incompatible dependencies that's for
>> you to fix.
> So --with-parmetis=/foo
> and then in David's case he'd precompile parmetis and point petsc and
> libmesh to the same one?
headers and libraries someplace accessible, in which case only libMesh
would need non-default options.
The PETSc parmetis build goes into $PETSC_DIR/externalpackages/parmetis-<version>
We currently install 4.0.2. Note that PETSc can use a different parmetis if at configure
time the user supplies --with-parmetis-dir=<parmetis-install-dir> or --with-parmetis-include=<parmetis-include-dir>