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