On Thu, 26 Apr 2012, Kirk, Benjamin (JSC-EG311) wrote: > I've moved this to the -devel to set a bit for discussion. For things that > we include as contributed packages, but we might reasonably expect other > people to have, we might consider "prefixing" our includes in the old > 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? 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. --- 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
