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.
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. 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. Would you find this more convenient? If so, I am willing to make the transition. Jack On Fri, Aug 31, 2012 at 4:12 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > On Fri, Aug 31, 2012 at 3:17 PM, Jack Poulson <jack.poulson at > gmail.com>wrote: > >> I seemed to have ignored your question. >> >> If compatible versions of the library are used in package "X", then >> everything should work fine. Is there a problem which you are expecting? >> > > 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. > > >> 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... > > > 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. > > >> >> Jack >> >> On Fri, Aug 31, 2012 at 2:28 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: >> >>> 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? >>> On Aug 31, 2012 1:49 PM, "Satish Balay" <balay at mcs.anl.gov> wrote: >>> >>>> Should have cc:d to petsc-dev >>>> >>>> context: >>>> >>>> clique packages metis,parmetis,elemental sources in a single bundle. >>>> So we were attempting to build them separately [from petsc configure]. >>>> >>>> Jack has extensions to metis and parmetis functionality - thats used >>>> in clique. We tried to split this out into separate -lparmetis-addons >>>> library [using parmetis public includes] so that our current >>>> -lparmetis could be used. But this doesn't work as it needs parmetis >>>> private includes. >>>> >>>> So looks like we'll have to add these extensions to the metis/parmetis >>>> tarballs we distribute [and have common metis/parmetis sources >>>> available for both petsc an clique] >>>> >>>> Satish >>>> >>>> On Fri, 31 Aug 2012, Satish Balay wrote: >>>> >>>> > On Fri, 31 Aug 2012, Satish Balay wrote: >>>> > >>>> > > On Fri, 31 Aug 2012, Jack Poulson wrote: >>>> > > >>>> > > > > Also does clique also build elemental? Can we split it up >>>> aswell with >>>> > > > > MANUAL_ELEMENTAL, ELEMENTAL_INCLUDE_DIR, ELEMENTAL_LIBS options? >>>> > > > > >>>> > > > > >>>> > > > I will take care of all of these issues as soon as I get a >>>> chance. Clique >>>> > > > does currently build Elemental (it sits in external/elemental). >>>> If both >>>> > > > Clique and Elemental are both to be used in the same package, I >>>> would think >>>> > > > it would make sense to just install Clique and use its version of >>>> > > > Elemental. Is there a problem with this approach? It ensures >>>> compatibility. >>>> > > >>>> > > I'll have to check this - but 2 ways of building the same thing is >>>> not >>>> > > easy in petsc build tools. Esp when we provide --with-elemental-dir >>>> > > option to configure. >>>> > > >>>> > > Sure we'll have to make sure the compatible elemental,clique are >>>> > > installed - when both are installed by petsc [or by user] >>>> > >>>> > Jack, >>>> > >>>> > [I'm having to add the flag BUILD_PARMETIS=0.] But now I get: >>>> > >>>> > 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 >>>> > >>>> /home/balay/spetsc/externalpackages/clique/src/parmetis/ParallelBisect.c:5:25: >>>> fatal error: parmetislib.h: No such file or directory >>>> > >>>> > Looks like this code needs parmetis private includes. So the current >>>> > stratergy [of splitting into -lparmetis-addons] isn't working. >>>> > >>>> > Perhaps we'll have to use a single patched metis/parmetis tarball for >>>> > both petsc and clique afterall.. >>>> > >>>> > Satish >>>> > >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120831/b226f2fb/attachment-0001.html>
