On Mon, 27 Feb 2017, Satish Balay wrote: > On Mon, 27 Feb 2017, Marco Atzeri wrote: > > > On 27/02/2017 19:15, Satish Balay wrote: > > > Ah - previously I didn't check the error log closely. > > > > > > > > > > > > > > Using PETSC_DIR=/usr/local and PETSC_ARCH= > > > > > C/C++ example src/snes/examples/tutorials/ex19 run successfully with 1 > > > > > MPI process > > > > > C/C++ example src/snes/examples/tutorials/ex19 run successfully with 2 > > > > > MPI processes > > > <<<<< > > > > > > So the C tests did run fine. [with openmpi build] > > > > the trick seems to copy/move the shared libs from > > usr/local/lib to /usr/local/bin so that libpetsc.so.3.7.5 > > is on the PATH. > > Yeah - we now do 'PATH=$PATH:$PETSC_DIR/$PETSC_ARCH/lib make test' > [instead of the copy to bin]. Most PETSc installs shouldn't go into > /usr/loca/bin anyway. > > > > > > > > > > > > > > > Possible error running C/C++ src/snes/examples/tutorials/ex19 with 1 > > > > > MPI > > > > > process > > > <<<< > > > > > > Hm - the test for sequential build failed? Perhaps you had some mixup > > > of files with the previous openmpi build. > > > When changing builds (like switching mpi) - its best to remove build > > > files in PETSC_ARCH - and install files in prefix-dir - before the > > > next build. Or use a different PETSC_ARCH/prefix values for the > > > second build. > > > > I am using in general different directories. > > I will try again just in case I missed something. > > > > > I tried both builds - and they ran fine for me. [with maint/3.7] > > > > > > Either way - fortran examples don't work with dlls - so its best to > > > use --with-shared-libraries=0 > > > > don't work in general or just for cygwin ? > > PETSc fortran interface uses fortran common blocks - and DLLs (with > common blocks) require some compiler directives (perhaps compiler > specific wrt ifort vs gfortran) to handle this. > > We don't yet have that in petsc. > > > > > additional question : > > - where is defined the `libpetsc.so.3.7.5` name for the shared lib ? > > > > I would prefer to use the cygwin standard nomenclature. > > You can run 'make V=1' to check the exact command used to create > libpetsc.dll - and figure out appropriate the modification for cygwin. > > >>>> > gcc -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas > -fstack-protector -fvisibility=hidden -g3 -shared > -Wl,-soname,libpetsc.so.3.07 -o > /home/balay/petsc/arch-mswin-c-debug/lib/libpetsc.so.3.07.5 > arch-mswin-c-debug/obj/src/sys/objects/f2003-src/fsrc/optionenum.o ..... > <<<< > > configure sets some of these options in SL_LINKER_FUNCTION variable in > PETSC_ARCH/lib/petsc/conf/petscvariables file > > >>>> > SL_LINKER_FUNCTION = -shared -Wl,-soname,$(call SONAME_FUNCTION,$(notdir > $(1)),$(2)) > <<<<
Also: SONAME_FUNCTION = $(1).so.$(2) Satish > > This gets used by PETSC_DIR/gmakefile [you can look for all SL_LINKER usage > here] when building the dll. > > Perhaps SL_LINKER_FUNCTION in PETSC_ARCH/lib/petsc/conf/petscvariables > can be changed sufficiently to get the appropriate naming for cygwin. > > Satish >
