>> 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. > 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? We can do that easily enough, I'll just point out to David that means for the configuration he wants he'll have to precompile - exodusII - netcdf - metis - parmetis - ??? But I'd ask if you really need Seive enabled in the same PETSc that libmesh is using? Certainly easier to just define a different PETSC_ARCH that libmesh uses that doesn't contain the conflicting libraries... -Ben ------------------------------------------------------------------------------ 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
