Re: [Libmesh-devel] [Libmesh-users] libmesh failing to build with sieve enabled in petsc

[Kirk, B. (JSC-EG311) <ben...@na...>]

>> 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