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

[Jose E. Roman]

> El 22 ago 2018, a las 12:52, Matthew Knepley <knepley at gmail.com> escribió:
> 
> 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.

Another fix is to have a custom Fortran stub for KSPFGMRESModifyPCKSP() and KSPFGMRESModifyPCNoChange(), rather than an automatic Fortran stub. That is, change /*@ to /*@C and add a definition for these functions in zmodpcff.c

Jose
 

> 
>    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/