<div class="gmail_quote">On Fri, Aug 31, 2012 at 4: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">
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></blockquote><div><br></div><div>I think this the Right Way.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
</div></blockquote><div><br></div><div>I'm not a fan of the rampant duplication implied by header-only, but do as you like.<br><br>Note that elemental/config.h is somewhat concerning because if any part of the configuration is different (even for matching versions), you can have duplicate symbols with different implementations. The linker is free to take any implementation from anywhere. This can cause tricky run-time bugs such as the version used to allocate being different from the version used to deallocate.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>Would you find this more convenient? If so, I am willing to make the transition.<span class="HOEnZb"><font color="#888888"><br><br>Jack</font></span><div><div class="h5"><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>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>
<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><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></div></div>
</blockquote></div><br>