On Thu, 26 Apr 2012, Kirk, Benjamin (JSC-EG311) wrote: >>> C-style? For background, David is having a parmetis version clash between >>> 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.
My thoughts exactly. >> 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? Right - unless the default PETSc install already leaves parmetis headers and libraries someplace accessible, in which case only libMesh would need non-default options. --- Roy ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
