[petsc-dev] Undefined symbols for _kspfgmresmodifypcksp_ and _kspfgmresmodifypcnochange_ when rebuilding

[Matthew Knepley]

On Wed, Aug 22, 2018 at 6:35 AM Lawrence Mitchell <lawrence at wence.uk> wrote:

>
> > On 22 Aug 2018, at 10:04, Patrick Sanan <patrick.sanan at gmail.com> wrote:
> >
> > This happens fairly frequently when I try to switch/update branches of
> PETSc (here invoked by building my own code, but the error message looks
> the same with "make check"):
> >
> > $ make
> >
> /Users/patrick/petsc-stagbl/arch-darwin-stagbl-double-extra-debug/bin/mpicc
> -o runme.o -c -Wall -Wwrite-strings -Wno-strict-aliasing
> -Wno-unknown-pragmas -fstack-protector -fvisibility=hidden -g3
>  -I/Users/patrick/petsc-stagbl/include
> -I/Users/patrick/petsc-stagbl/arch-darwin-stagbl-double-extra-debug/include
> -I/opt/X11/include    `pwd`/runme.c
> >
> /Users/patrick/petsc-stagbl/arch-darwin-stagbl-double-extra-debug/bin/mpicc
> -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress
> -Wl,-commons,use_dylibs -Wl,-search_paths_first -Wl,-no_compact_unwind
> -Wl,-multiply_defined,suppress -Wl,-multiply_defined -Wl,suppress
> -Wl,-commons,use_dylibs -Wl,-search_paths_first -Wl,-no_compact_unwind
> -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas
> -fstack-protector -fvisibility=hidden -g3  -o runme runme.o
> -Wl,-rpath,/Users/patrick/petsc-stagbl/arch-darwin-stagbl-double-extra-debug/lib
> -L/Users/patrick/petsc-stagbl/arch-darwin-stagbl-double-extra-debug/lib
> -Wl,-rpath,/Users/patrick/petsc-stagbl/arch-darwin-stagbl-double-extra-debug/lib
> -Wl,-rpath,/opt/X11/lib -L/opt/X11/lib
> -Wl,-rpath,/opt/local/lib/gcc7/gcc/x86_64-apple-darwin17/7.3.0
> -L/opt/local/lib/gcc7/gcc/x86_64-apple-darwin17/7.3.0
> -Wl,-rpath,/opt/local/lib/gcc7 -L/opt/local/lib/gcc7 -lpetsc -lcmumps
> -ldmumps -lsmumps -lzmumps -lmumps_common -lpord -lscalapack -lumfpack
> -lklu -lcholmod -lbtf -lccolamd -lcolamd -lcamd -lamd -lsuitesparseconfig
> -lsuperlu_dist -lHYPRE -lsundials_cvode -lsundials_nvecserial
> -lsundials_nvecparallel -llapack -lblas -lparmetis -lmetis -lX11 -lyaml
> -lstdc++ -ldl -lmpifort -lmpi -lpmpi -lgfortran -lquadmath -lm -lstdc++ -ldl
> > Undefined symbols for architecture x86_64:
> >   "_kspfgmresmodifypcksp_", referenced from:
> >       import-atom in libpetsc.dylib
> >   "_kspfgmresmodifypcnochange_", referenced from:
> >       import-atom in libpetsc.dylib
> > ld: symbol(s) not found for architecture x86_64
> > collect2: error: ld returned 1 exit status
> >
> > I don't know why this is, exactly. Maybe it's more obvious from the
> perspective of someone more expert on the Fortran interface, and we could
> save some time reconfiguring (if these two symbols are really the only
> issue).
> >
> >  For these two symbols, the corresponding functions are declared but not
> defined in
> >
> >     src/ksp/ksp/impls/gmres/fgmres/ftn-custom/zmodpcff.c
> >
> > "make deletefortranstubs" by itself doesn't seem to solve the problem.
> My sledgehammer workaround is to do everything short of blowing away my
> entire $PETSC_ARCH directory:
> >
> >     make deletefortranstubs && make allclean && make reconfigure && make
> && make check
>
>
> Does it work to do:
>
> make allfortranstubs && make
>
> In these cases?
>

Lawrence is correct. Here is what is happening.

Someone changes an interface, and you pull the change. The header changes
will cause all the C files
using that API to rebuild. However, the doc system (sowing) runs bfort on
the C file to generate the Fortran
binding. It runs on all headers at once, so there is no separately rule for
bforting a C file when it changes.
Things are now even worse, since we have Python code separate from bfort
which create the Fortran
modules, which also will not fire on updates to the C file.

The simplest fix is that you know that every time you see this problem, you
rerun 'make allfortranstubs'.
The complicate fix is to rewrite bfort and the module generation into one
program which respects the
dependency information. Since there is literally no credit associated with
this job, it is unlikely ever to happen.
We await the passing of the last Fortran programmer.

   Matt


> I used to have to do this, until eventually I gave up and built without
> the fortran interfaces (may not be an option).
>
> I tried to unpick the make rules so that if you built with fortran
> interfaces, the generation of individual interface would depend on the
> relevant C files, but gave up, because I couldn't see what was going on.
>
> Cheers,
>
> Lawrence



-- 
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/ <http://www.caam.rice.edu/~mk51/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180822/59483f09/attachment.html>