[petsc-dev] configure failed after update of OSX

Barry Smith bsmith at mcs.anl.gov
Wed Jan 29 08:15:11 CST 2014


On Jan 29, 2014, at 6:26 AM, Jed Brown <jed at jedbrown.org> wrote:

> Geoff Oxberry <goxberry at gmail.com> writes:
>> I can answer some Homebrew questions. I typically skim petsc-dev and
>> petsc-users due to my relative PETSc inexperience, and only read a few
>> posts here and there. If someone bugs you about it and I miss it, ping me,
>> and I'll do my best to help. PETSc is also a package in the
>> homebrew-science repo, so I can lean on some of them for help also. I've
>> learned to build PETSc from source because the package builds in Linux
>> distros and Mac package managers usually lack the external package
>> capabilities I want (and they're old versions, too).
> 
> For systems with shared libraries, it may be useful to have a way to add
> plugins after building PETSc, rather than asking packagers to build
> every subset or a maximal subset.  The problem is that functions like
> PCHYPRESetType() are made visible to the user and thus become link-time
> dependencies.  Is there something *maintainable* we could do to allow
> applications to link without the packages?
> 
> Functions like the above either do PetscTryMethod or PetscUseMethod so
> they don't have a link-time dependency on the implementation
> PCHYPRESetType_HYPRE (and thus the external package), but are currently
> placed in the file with the external package.  If we moved them
> somewhere that was always compiled, we would get rid of the link-time
> dependency and then we could add these plugins after installing the
> PETSc base system.  It's not a huge amount of code wrangling to move
> these functions, but it means that adding a new function necessarily
> involves modifying three files (it already involves include/petscyyy.h
> and src/yyy/impls/zzz/zzz.c).

   It was always the intention since like 1996 to pull those out and make them separate. Possibly even as include files only. But aside from theoretical reasons we never had demand that actually made us do it. Could be a chicken and egg thing.

   Barry

> 
> We still also need the monolithic mode to keep linking sane on systems
> without shared libraries.




More information about the petsc-dev mailing list