February 2017 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] build on cygwin for cygwin
by Satish Balay 27 Feb '17

27 Feb '17

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 >

1 0

Re: [petsc-dev] build on cygwin for cygwin
by Satish Balay 27 Feb '17

27 Feb '17

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

1 0

Re: [petsc-dev] build on cygwin for cygwin
by Marco Atzeri 27 Feb '17

27 Feb '17

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. >>>> >>> 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 ? > Satish 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. Regards Marco

1 0

Re: [petsc-dev] build on cygwin for cygwin
by Satish Balay 27 Feb '17

27 Feb '17

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] >>> > > 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 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 Satish On Mon, 27 Feb 2017, Satish Balay wrote: > dll build has issues - so its best to use --with-shared-libraries=0 on windows builds. > > Normally c examples should work [without fortran] with dlls - will take a look. > > Satish > > On Mon, 27 Feb 2017, Marco Atzeri wrote: > > > Dear developers, > > > > from documentation > > https://www.mcs.anl.gov/petsc/documentation/installation.html > > > > seems that a build with cygwin compiler is possible, however > > the results seems puzzling. > > > > I tried with opemmpi compilers on x86_64 platform > > > > --with-cc=mpicc --with-cxx=mpic++ --with-fc=mpifort --prefix=/usr/local > > PETSC_ARCH=arch-mswin-gnu > > > > and I see that the shared libraries have incorrect names > > > > ./arch-mswin-gnu/lib/libpetsc.dll > > ./arch-mswin-gnu/lib/libpetsc.so.3.7 > > ./arch-mswin-gnu/lib/libpetsc.so.3.7.5 > > > > the right one should be cygpetsc-SONAME.dll; > > The dependencies are correct > > > > $ cygcheck arch-mswin-gnu/lib/libpetsc.so.3.7.5 |grep "^ E" > > E:\cygwin64\bin\cyggcc_s-seh-1.dll > > E:\cygwin64\bin\cyggfortran-3.dll > > E:\cygwin64\bin\cygblas-0.dll > > E:\cygwin64\bin\cygcrypto-1.0.0.dll > > E:\cygwin64\lib\lapack\cyglapack-0.dll > > E:\cygwin64\bin\cygmpi-12.dll > > E:\cygwin64\bin\cygmpi_mpifh-12.dll > > E:\cygwin64\bin\cygssl-1.0.0.dll > > E:\cygwin64\bin\cygX11-6.dll > > > > there is no trace of import library ( *.a or *.lib) > > > > Almost all tests fails. > > -- > > $ make PETSC_DIR=/usr/local PETSC_ARCH="" test > > Running test examples to verify correct installation > > 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 > > Possible error running Fortran example src/snes/examples/tutorials/ex5f with 1 > > MPI process > > See http://www.mcs.anl.gov/petsc/documentation/faq.html > > [0]PETSC ERROR: --------------------- Error Message > > -------------------------------------------------------------- > > [0]PETSC ERROR: Object is in wrong state > > [0]PETSC ERROR: Cannot set ownership ranges before setting number of procs > > [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for > > trouble shooting. > > [0]PETSC ERROR: Petsc Release Version 3.7.5, Jan, 01, 2017 > > [0]PETSC ERROR: ./ex5f on a arch-mswin-gnu named GE-MATZERI-EU by 0356EU Mon > > Feb 27 18:10:42 2017 > > [0]PETSC ERROR: Configure options --with-cc=mpicc --with-cxx=mpic++ > > --with-fc=mpifort --prefix=/usr/local PETSC_ARCH=arch-mswin-gnu > > [0]PETSC ERROR: #1 DMDASetOwnershipRanges() line 617 in > > /cygdrive/e/cyg_pub/devel/petsc/prova4/petsc-3.7.5/src/dm/impls/da/da.c > > [0]PETSC ERROR: #2 DMDACreate2d() line 863 in > > /cygdrive/e/cyg_pub/devel/petsc/prova4/petsc-3.7.5/src/dm/impls/da/da2.c > > -- > > > > > > I also tried a build without mpi --with-mpi=0 > > but the tests seem to call mpi anyway: > > -- > > Possible error running C/C++ src/snes/examples/tutorials/ex19 with 1 MPI > > process > > See http://www.mcs.anl.gov/petsc/documentation/faq.html > > [0]PETSC ERROR: > > ------------------------------------------------------------------------ > > [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably > > memory access out of range > > -- > > that is at least curious. > > > > > > Question: > > - have some recently built successfully on cygwin for cygwin ? > > > > Looking at build scripts on config directory I have the impression > > that cygwin is only used as platform to build for Windows and not for cygwin > > itself. > > > > > > Thanks in advance > > Marco > > > > > > > > > > > >

1 0

Re: [petsc-dev] build on cygwin for cygwin
by Satish Balay 27 Feb '17

27 Feb '17

dll build has issues - so its best to use --with-shared-libraries=0 on windows builds. Normally c examples should work [without fortran] with dlls - will take a look. Satish On Mon, 27 Feb 2017, Marco Atzeri wrote: > Dear developers, > > from documentation > https://www.mcs.anl.gov/petsc/documentation/installation.html > > seems that a build with cygwin compiler is possible, however > the results seems puzzling. > > I tried with opemmpi compilers on x86_64 platform > > --with-cc=mpicc --with-cxx=mpic++ --with-fc=mpifort --prefix=/usr/local > PETSC_ARCH=arch-mswin-gnu > > and I see that the shared libraries have incorrect names > > ./arch-mswin-gnu/lib/libpetsc.dll > ./arch-mswin-gnu/lib/libpetsc.so.3.7 > ./arch-mswin-gnu/lib/libpetsc.so.3.7.5 > > the right one should be cygpetsc-SONAME.dll; > The dependencies are correct > > $ cygcheck arch-mswin-gnu/lib/libpetsc.so.3.7.5 |grep "^ E" > E:\cygwin64\bin\cyggcc_s-seh-1.dll > E:\cygwin64\bin\cyggfortran-3.dll > E:\cygwin64\bin\cygblas-0.dll > E:\cygwin64\bin\cygcrypto-1.0.0.dll > E:\cygwin64\lib\lapack\cyglapack-0.dll > E:\cygwin64\bin\cygmpi-12.dll > E:\cygwin64\bin\cygmpi_mpifh-12.dll > E:\cygwin64\bin\cygssl-1.0.0.dll > E:\cygwin64\bin\cygX11-6.dll > > there is no trace of import library ( *.a or *.lib) > > Almost all tests fails. > -- > $ make PETSC_DIR=/usr/local PETSC_ARCH="" test > Running test examples to verify correct installation > 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 > Possible error running Fortran example src/snes/examples/tutorials/ex5f with 1 > MPI process > See http://www.mcs.anl.gov/petsc/documentation/faq.html > [0]PETSC ERROR: --------------------- Error Message > -------------------------------------------------------------- > [0]PETSC ERROR: Object is in wrong state > [0]PETSC ERROR: Cannot set ownership ranges before setting number of procs > [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for > trouble shooting. > [0]PETSC ERROR: Petsc Release Version 3.7.5, Jan, 01, 2017 > [0]PETSC ERROR: ./ex5f on a arch-mswin-gnu named GE-MATZERI-EU by 0356EU Mon > Feb 27 18:10:42 2017 > [0]PETSC ERROR: Configure options --with-cc=mpicc --with-cxx=mpic++ > --with-fc=mpifort --prefix=/usr/local PETSC_ARCH=arch-mswin-gnu > [0]PETSC ERROR: #1 DMDASetOwnershipRanges() line 617 in > /cygdrive/e/cyg_pub/devel/petsc/prova4/petsc-3.7.5/src/dm/impls/da/da.c > [0]PETSC ERROR: #2 DMDACreate2d() line 863 in > /cygdrive/e/cyg_pub/devel/petsc/prova4/petsc-3.7.5/src/dm/impls/da/da2.c > -- > > > I also tried a build without mpi --with-mpi=0 > but the tests seem to call mpi anyway: > -- > Possible error running C/C++ src/snes/examples/tutorials/ex19 with 1 MPI > process > See http://www.mcs.anl.gov/petsc/documentation/faq.html > [0]PETSC ERROR: > ------------------------------------------------------------------------ > [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably > memory access out of range > -- > that is at least curious. > > > Question: > - have some recently built successfully on cygwin for cygwin ? > > Looking at build scripts on config directory I have the impression > that cygwin is only used as platform to build for Windows and not for cygwin > itself. > > > Thanks in advance > Marco > > > > >

1 0

Re: [petsc-dev] nightly build problems because dependencies are not properly listed in tests!
by Jed Brown 27 Feb '17

27 Feb '17

Satish Balay <balay(a)mcs.anl.gov> writes: > Sorry - this is a win32fe issue. I'm attempting to fix it in > win32fe. Will push it once I test my fix.. > > The issue is: win32fe tries to keep objfiles as .o [same as linux] - > and then moves files over to .obj - for the link step. Currently its > storing this in $TMP. So when multiple (make) threads compile ex1.c > simultaneously [in different example dirs] - they get mapped into > $TMP/ex1.obj - so the wrong objfile can get linked into the executable > by one of the threads. > > My current fix is to change win32fe to create .obj in the same > location as .o Thanks for the explanation. For what it's worth, I don't see a problem with having configure detect the *.obj naming and having our makefile work with it directly. Perhaps that would be a simpler and more transparent for the user.

1 0

Re: [petsc-dev] nightly build problems because dependencies are not properly listed in tests!
by Satish Balay 27 Feb '17

27 Feb '17

On Mon, 27 Feb 2017, Satish Balay wrote: > On Mon, 27 Feb 2017, Jed Brown wrote: > > > Scott Kruger <kruger(a)txcorp.com> writes: > > > > > On 2/27/17 10:06 AM, Tobin Isaac wrote: > > >> On Sun, Feb 26, 2017 at 09:57:25PM -0600, Barry Smith wrote: > > >>> > > >>> # [0]PETSC ERROR: Mesh generation needs external package support. > > >>> # Please reconfigure with --download-triangle. > > >>> > > >>> is appearing in a bunch of nightly build errors > > >>> > > >>> http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2017/02/26/examples_fu… > > >>> > > >>> Please make sure you list all package dependencies in your test cases before pushing a branch to next. Though Jonathan Shewchuk is a god of programming this does not mean that triangle is always installed on all computers at birth. You waste everybody's time by not handling these basics before pushing to next, plus you slow down the process of moving your branch to master. > > >>> > > >> > > >> Good advice, but the specific problem here is win32fe + intel > > >> compilers wants to mixup the executables between directories. Satish > > >> and I have had a thread on this. > > >> > > > > > > It looks to me like a gmake bug, but we need verbose > > > output and some debugging to be sure. > > > > What do I need to reproduce it? > > Sorry - this is a win32fe issue. I'm attempting to fix it in > win32fe. Will push it once I test my fix.. Added fix to balay/fix-win32fe-tmp-obj-usage and merged to next now. Satish > > The issue is: win32fe tries to keep objfiles as .o [same as linux] - > and then moves files over to .obj - for the link step. Currently its > storing this in $TMP. So when multiple (make) threads compile ex1.c > simultaneously [in different example dirs] - they get mapped into > $TMP/ex1.obj - so the wrong objfile can get linked into the executable > by one of the threads. > > My current fix is to change win32fe to create .obj in the same > location as .o > > Satish >

1 0

build on cygwin for cygwin
by Marco Atzeri 27 Feb '17

27 Feb '17

Dear developers, from documentation https://www.mcs.anl.gov/petsc/documentation/installation.html seems that a build with cygwin compiler is possible, however the results seems puzzling. I tried with opemmpi compilers on x86_64 platform --with-cc=mpicc --with-cxx=mpic++ --with-fc=mpifort --prefix=/usr/local PETSC_ARCH=arch-mswin-gnu and I see that the shared libraries have incorrect names ./arch-mswin-gnu/lib/libpetsc.dll ./arch-mswin-gnu/lib/libpetsc.so.3.7 ./arch-mswin-gnu/lib/libpetsc.so.3.7.5 the right one should be cygpetsc-SONAME.dll; The dependencies are correct $ cygcheck arch-mswin-gnu/lib/libpetsc.so.3.7.5 |grep "^ E" E:\cygwin64\bin\cyggcc_s-seh-1.dll E:\cygwin64\bin\cyggfortran-3.dll E:\cygwin64\bin\cygblas-0.dll E:\cygwin64\bin\cygcrypto-1.0.0.dll E:\cygwin64\lib\lapack\cyglapack-0.dll E:\cygwin64\bin\cygmpi-12.dll E:\cygwin64\bin\cygmpi_mpifh-12.dll E:\cygwin64\bin\cygssl-1.0.0.dll E:\cygwin64\bin\cygX11-6.dll there is no trace of import library ( *.a or *.lib) Almost all tests fails. -- $ make PETSC_DIR=/usr/local PETSC_ARCH="" test Running test examples to verify correct installation 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 Possible error running Fortran example src/snes/examples/tutorials/ex5f with 1 MPI process See http://www.mcs.anl.gov/petsc/documentation/faq.html [0]PETSC ERROR: --------------------- Error Message -------------------------------------------------------------- [0]PETSC ERROR: Object is in wrong state [0]PETSC ERROR: Cannot set ownership ranges before setting number of procs [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html for trouble shooting. [0]PETSC ERROR: Petsc Release Version 3.7.5, Jan, 01, 2017 [0]PETSC ERROR: ./ex5f on a arch-mswin-gnu named GE-MATZERI-EU by 0356EU Mon Feb 27 18:10:42 2017 [0]PETSC ERROR: Configure options --with-cc=mpicc --with-cxx=mpic++ --with-fc=mpifort --prefix=/usr/local PETSC_ARCH=arch-mswin-gnu [0]PETSC ERROR: #1 DMDASetOwnershipRanges() line 617 in /cygdrive/e/cyg_pub/devel/petsc/prova4/petsc-3.7.5/src/dm/impls/da/da.c [0]PETSC ERROR: #2 DMDACreate2d() line 863 in /cygdrive/e/cyg_pub/devel/petsc/prova4/petsc-3.7.5/src/dm/impls/da/da2.c -- I also tried a build without mpi --with-mpi=0 but the tests seem to call mpi anyway: -- Possible error running C/C++ src/snes/examples/tutorials/ex19 with 1 MPI process See http://www.mcs.anl.gov/petsc/documentation/faq.html [0]PETSC ERROR: ------------------------------------------------------------------------ [0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range -- that is at least curious. Question: - have some recently built successfully on cygwin for cygwin ? Looking at build scripts on config directory I have the impression that cygwin is only used as platform to build for Windows and not for cygwin itself. Thanks in advance Marco

1 0

Re: [petsc-dev] nightly build problems because dependencies are not properly listed in tests!
by Satish Balay 27 Feb '17

27 Feb '17

On Mon, 27 Feb 2017, Jed Brown wrote: > Scott Kruger <kruger(a)txcorp.com> writes: > > > On 2/27/17 10:06 AM, Tobin Isaac wrote: > >> On Sun, Feb 26, 2017 at 09:57:25PM -0600, Barry Smith wrote: > >>> > >>> # [0]PETSC ERROR: Mesh generation needs external package support. > >>> # Please reconfigure with --download-triangle. > >>> > >>> is appearing in a bunch of nightly build errors > >>> > >>> http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2017/02/26/examples_fu… > >>> > >>> Please make sure you list all package dependencies in your test cases before pushing a branch to next. Though Jonathan Shewchuk is a god of programming this does not mean that triangle is always installed on all computers at birth. You waste everybody's time by not handling these basics before pushing to next, plus you slow down the process of moving your branch to master. > >>> > >> > >> Good advice, but the specific problem here is win32fe + intel > >> compilers wants to mixup the executables between directories. Satish > >> and I have had a thread on this. > >> > > > > It looks to me like a gmake bug, but we need verbose > > output and some debugging to be sure. > > What do I need to reproduce it? Sorry - this is a win32fe issue. I'm attempting to fix it in win32fe. Will push it once I test my fix.. The issue is: win32fe tries to keep objfiles as .o [same as linux] - and then moves files over to .obj - for the link step. Currently its storing this in $TMP. So when multiple (make) threads compile ex1.c simultaneously [in different example dirs] - they get mapped into $TMP/ex1.obj - so the wrong objfile can get linked into the executable by one of the threads. My current fix is to change win32fe to create .obj in the same location as .o Satish

1 0

Re: [petsc-dev] nightly build problems because dependencies are not properly listed in tests!
by Tobin Isaac 27 Feb '17

27 Feb '17

On Mon, Feb 27, 2017 at 09:42:06AM -0700, Jed Brown wrote: > Scott Kruger <kruger(a)txcorp.com> writes: > > > On 2/27/17 10:06 AM, Tobin Isaac wrote: > >> On Sun, Feb 26, 2017 at 09:57:25PM -0600, Barry Smith wrote: > >>> > >>> # [0]PETSC ERROR: Mesh generation needs external package support. > >>> # Please reconfigure with --download-triangle. > >>> > >>> is appearing in a bunch of nightly build errors > >>> > >>> http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2017/02/26/examples_fu… > >>> > >>> Please make sure you list all package dependencies in your test cases before pushing a branch to next. Though Jonathan Shewchuk is a god of programming this does not mean that triangle is always installed on all computers at birth. You waste everybody's time by not handling these basics before pushing to next, plus you slow down the process of moving your branch to master. > >>> > >> > >> Good advice, but the specific problem here is win32fe + intel > >> compilers wants to mixup the executables between directories. Satish > >> and I have had a thread on this. > >> > > > > It looks to me like a gmake bug, but we need verbose > > output and some debugging to be sure. > > What do I need to reproduce it? Good question. The original thread is here: http://lists.mcs.anl.gov/pipermail/petsc-dev/2017-February/020456.html Summary: - I have tests in src/vec/vec/utils/tagger/examples/tutorials/ex1.c - They are being run on the executable generated from src/dm/impls/plex/examples/tests/ex1.c - The problem only crops up on mswin-intel test builds: not mswin-gnu, or mswin-uni which uses "win32fe cl". - It happens consistently, so it doesn't appear to be a race condition

1 0