Sorry for the confusion surrounding this issue. Your code needs to go in its
own standalone library that links against both PETSc and SLEPc. You can just
the mechanism Jed suggested to have your library call PCRegister() when it is
utilized (see previous emails/discussion). You could perhaps look at how the
ctetgen package utilizes the PETSc compile system and copy that for your
makefile and SLEPc, of course.
Once you have the "framework" that does this you could make a PR labeled
something like WIP and ask for help in getting the details right.
Barry
> On Jul 8, 2019, at 9:58 AM, Pierre Jolivet via petsc-dev
> <petsc-dev@mcs.anl.gov> wrote:
>
> Hello,
> I’m not sure what’s the status about this issue.
> I’m trying to register a PC that is using EPSSolve during PCSetUp, but it’s
> falling because of undefined references to EPSSomething when linking
> libpetsc.so
> How could I fix this, appart from removing my PC from PETSc and compiling
> this as a separate library (the idea would be to merge my PC in PETSc, so
> that would be rather counterproductive in the end)?
>
> Thanks,
> Pierre
>
>> On 27 Jun 2019, at 1:04 AM, Matthew Knepley via petsc-dev
>> <petsc-dev@mcs.anl.gov> wrote:
>>
>> On Wed, Jun 26, 2019 at 4:11 PM Jed Brown <j...@jedbrown.org> wrote:
>> Matthew Knepley <knep...@gmail.com> writes:
>>
>> > On Wed, Jun 26, 2019 at 3:42 PM Jed Brown via petsc-dev <
>> > petsc-dev@mcs.anl.gov> wrote:
>> >
>> >> "Smith, Barry F." <bsm...@mcs.anl.gov> writes:
>> >>
>> >> >> On Jun 26, 2019, at 1:53 PM, Jed Brown <j...@jedbrown.org> wrote:
>> >> >>
>> >> >> "Smith, Barry F." <bsm...@mcs.anl.gov> writes:
>> >> >>
>> >> >>> It is still a PC, it may as part of its computation solve an
>> >> eigenvalue problem but its use is as a PC, hence does not belong in SLEPc.
>> >> >>
>> >> >> Fine; it does not belong in src/ksp/pc/.
>> >> >
>> >> > Why not? From the code mangement point of view that is the perfect
>> >> place for it. It just depends on an external package in the same way that
>> >> PCHYPRE depends on an external library. Having it off in some other
>> >> directory src/plugins would serve no purpose. Of course making sure it
>> >> doesn't get compiled into -lpetsc may require a tweak to the make
>> >> infrastructure. Make could, for example, skip plugin subdirectories for
>> >> example.
>> >>
>> >> I think it's confusing to have code that is part of libpetsc.so
>> >> alongside code that is not (e.g., won't be accessible to users unless
>> >> they also build SLEPc and link the plugin).
>> >>
>> >> > BTW: Matt's perverse use of SNES from DMPLEx could also be fixed to
>> >> > work this way instead of the disgusting PetscObject casting used to
>> >> > cancel the SNES object.
>> >>
>> >> That code could be part of libpetscsnes.so.
>> >>
>> >
>> > What? I thought I moved everything to SNES a long time ago.
>>
>> I thought there was a place where SNES was cast to PetscObject. There
>> is DMAddField, but it's different.
>>
>> I can't find it right now. Yeah, AddField is waiting for a true
>> Discretization object.
>> I think its spelled G-O-D-O-T.
>>
>> PetscViewerVTKAddField is another example of code that uses PetscObject
>> to avoid depending on a higher level type like Vec.
>>
>> Viewer is a weird mixin with everything.
>>
>> Matt
>>
>> --
>> 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
>>
>> https://www.cse.buffalo.edu/~knepley/
>
