In these cases, it sounds like the current best option is then to avoid using the CMake build system and manually link Elemental and Clique. If you have any suggestions, I am happy to work towards them as soon as possible. <div>
<br></div><div>Satish's suggestion (which I agree with) is for me to add support in Clique's CMake build system for a user-specified Elemental library. </div><div><br></div><div>Yet another option is to avoid having any libelemental.a/libclique.a at all. There is very little in it anyway, as well over 99% of both libraries are in header files. <br>
<br>Would you find this more convenient? If so, I am willing to make the transition.<br><br>Jack<br><br><div class="gmail_quote">On Fri, Aug 31, 2012 at 4:12 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">On Fri, Aug 31, 2012 at 3:17 PM, Jack Poulson <span dir="ltr"><<a href="mailto:jack.poulson@gmail.com" target="_blank">jack.poulson@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I seemed to have ignored your question. <br><br>If compatible versions of the library are used in package "X", then everything should work fine. Is there a problem which you are expecting?<br></blockquote><div>
<br>
</div></div><div>Well, we may have duplicate symbols if we link an "equivalent" library twice. If we do as CMake does, the full path for the different libelemental.a will be passed to the linker.</div><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I recognize that there is a potential issue of a newer version of Elemental or Clique conflicting with an older version, but  surely you guys are willing to deal with external libraries also changing their syntax from time to time...</blockquote>

<div><br></div></div><div>I'm not concerned about version mismatch because that is an issue regardless of distribution if both libs are linked into the same executable. It's the duplicate symbols that bother me.</div>
<div><div class="h5"><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888"><div>
<br></div></font></span><div><span><font color="#888888">Jack<br><br></font></span><div class="gmail_quote"><div>On Fri, Aug 31, 2012 at 2:28 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>

</div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Jack, this bundling strategy is a distribution nightmare. Suppose that some other package "X" independent of clique also bundles Elemental. How does an application (or another library) use both X and clique?</p>


<div><div>

<div class="gmail_quote">On Aug 31, 2012 1:49 PM, "Satish Balay" <<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



Should have cc:d to petsc-dev<br>
<br>
context:<br>
<br>
clique packages metis,parmetis,elemental sources in a single bundle.<br>
So we were attempting to build them separately [from petsc configure].<br>
<br>
Jack has extensions to metis and parmetis functionality - thats used<br>
in clique. We tried to split this out into separate -lparmetis-addons<br>
library [using parmetis public includes] so that our current<br>
-lparmetis could be used.  But this doesn't work as it needs parmetis<br>
private includes.<br>
<br>
So looks like we'll have to add these extensions to the metis/parmetis<br>
tarballs we distribute [and have common metis/parmetis sources<br>
available for both petsc an clique]<br>
<br>
Satish<br>
<br>
On Fri, 31 Aug 2012, Satish Balay wrote:<br>
<br>
> On Fri, 31 Aug 2012, Satish Balay wrote:<br>
><br>
> > On Fri, 31 Aug 2012, Jack Poulson wrote:<br>
> ><br>
> > > > Also does clique also build elemental? Can we split it up aswell with<br>
> > > > MANUAL_ELEMENTAL, ELEMENTAL_INCLUDE_DIR, ELEMENTAL_LIBS options?<br>
> > > ><br>
> > > ><br>
> > > I will take care of all of these issues as soon as I get a chance. Clique<br>
> > > does currently build Elemental (it sits in external/elemental). If both<br>
> > > Clique and Elemental are both to be used in the same package, I would think<br>
> > > it would make sense to just install Clique and use its version of<br>
> > > Elemental. Is there a problem with this approach? It ensures compatibility.<br>
> ><br>
> > I'll have to check this - but 2 ways of building the same thing is not<br>
> > easy in petsc build tools. Esp when we provide --with-elemental-dir<br>
> > option to configure.<br>
> ><br>
> > Sure we'll have to make sure the compatible elemental,clique are<br>
> > installed - when both are installed by petsc [or by user]<br>
><br>
> Jack,<br>
><br>
> [I'm having to add the flag BUILD_PARMETIS=0.] But now I get:<br>
><br>
> cd /home/balay/spetsc/externalpackages/clique/arch-clique/src/parmetis && /usr/lib64/ccache/gcc   -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline -O0 -I/home/balay/spetsc/externalpackages/clique/arch-clique/external/elemental/include -I/home/balay/soft/linux64/mpich2-1.1/include -I/home/balay/spetsc/arch-clique/include -I/home/balay/spetsc/externalpackages/clique/external/parmetis/include -I/home/balay/spetsc/externalpackages/clique/external/parmetis/libparmetis -I/home/balay/spetsc/externalpackages/clique/external/parmetis/metis/GKlib -I/home/balay/spetsc/externalpackages/clique/external/parmetis/metis/include    -o CMakeFiles/parmetis-addons.dir/ParallelBisect.c.o   -c /home/balay/spetsc/externalpackages/clique/src/parmetis/ParallelBisect.c<br>




> /home/balay/spetsc/externalpackages/clique/src/parmetis/ParallelBisect.c:5:25: fatal error: parmetislib.h: No such file or directory<br>
><br>
> Looks like this code needs parmetis private includes. So the current<br>
> stratergy [of splitting into -lparmetis-addons] isn't working.<br>
><br>
> Perhaps we'll have to use a single patched metis/parmetis tarball for<br>
> both petsc and clique afterall..<br>
><br>
> Satish<br>
><br>
<br>
</blockquote></div>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div></div></div><br>
</blockquote></div><br></div>