On Mon, 27 Feb 2017, Satish Balay wrote: > On Mon, 27 Feb 2017, Jed Brown wrote: > > > Scott Kruger <[email protected]> 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_full_next.log > > >>> > > >>> 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 >
