On Fri, Aug 31, 2012 at 4:49 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Fri, Aug 31, 2012 at 4:17 PM, Jack Poulson <jack.poulson at > gmail.com>wrote: > >> 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. >> > > I think this the Right Way. > I believe its The Right Way@ (copyright Barry Smith 1995). Matt > > >> >> 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. >> > > I'm not a fan of the rampant duplication implied by header-only, but do as > you like. > > 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. > > >> >> 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 >>>>>> > >>>>>> >>>>>> >>>> >>> >> > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120831/1f11c8f8/attachment.html>
