Thanks all! "make allfortranstubs && make" is certainly practical enough for me. I'd naively been assuming that "make deletefortranstubs && make" would have the same effect.
2018-08-22 13:09 GMT+02:00 Jose E. Roman <jro...@dsic.upv.es>: > > > > El 22 ago 2018, a las 12:52, Matthew Knepley <knep...@gmail.com> > escribió: > > > > On Wed, Aug 22, 2018 at 6:35 AM Lawrence Mitchell <lawre...@wence.uk> > wrote: > > > > > On 22 Aug 2018, at 10:04, Patrick Sanan <patrick.sa...@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/ > >
