Experimental Physics and
Industrial Control System

Andrew Johnson via Core-talk <[email protected]> · Thu, 02 May 2019 16:59:42 -0000

> Would make delete these as incomplete intermediate files on error?

The compiler isn't returning an error status though, it just doesn't
seem to be creating the output file, or at least not the one we're
asking for. For example from the last build that failed (-256) before
Ralph fixed it, here's the build for ccl.c:

mingw32-make[3]: Entering directory 'C:/projects/epics-base-5e851/src/libCom/O.windows-x64-mingw'
gcc  -D_MINGW -O3 -Wall -m64 -DEPICS_BUILD_DLL -DEPICS_CALL_DLL -I. -I../O.Common -I. -I../../../src/libCom/osi/compiler/gcc -I../../../src/libCom/osi/compiler/default -I. -I../../../src/libCom/osi/os/WIN32 -I../../../src/libCom/osi/os/default -I.. -I../../../src/libCom/as -I../../../src/libCom/bucketLib -I../../../src/libCom/calc -I../../../src/libCom/cvtFast -I../../../src/libCom/cppStd -I../../../src/libCom/cxxTemplates -I../../../src/libCom/dbmf -I../../../src/libCom/ellLib -I../../../src/libCom/env -I../../../src/libCom/error -I../../../src/libCom/fdmgr -I../../../src/libCom/flex -I../../../src/libCom/freeList -I../../../src/libCom/gpHash -I../../../src/libCom/iocsh -I../../../src/libCom/log -I../../../src/libCom/macLib -I../../../src/libCom/misc -I../../../src/libCom/osi -I../../../src/libCom/pool -I../../../src/libCom/ring -I../../../src/libCom/taskwd -I../../../src/libCom/timer -I../../../src/libCom/yacc -I../../../src/libCom/yacc -I../../../src/libCom/yajl -I../../../include/compiler/gcc -I../../../include/os/WIN32 -I../../../include -o ccl.obj -c ../../../src/libCom/flex/ccl.c
mingw32-make[3]: Leaving directory 'C:/projects/epics-base-5e851/src/libCom/O.windows-x64-mingw'

Then later when make tries to use ccl.obj it just gives:

mingw32-make[3]: *** No rule to make target 'ccl.obj', needed by
'e_flex.exe'.  Stop.

Hmm, since the appveyor-prepare.bat script installs my Make-4.1 for all builds (Make-4.2.1 is also available), why don't the mingw builds use it? The above messages show that they're using mingw32-make, confirmed by the appveyor-make.bat file.

@Ralph  I see this is using an older ActiveState Perl, is that configurable somehow? The latest StrawberryPerl packages (available through Chocolatey) install GNU Make-4.2.1 (named "gmake") and gcc as well, so they provide everything we need for a MinGW build. That's what I'm using here and had no problems with.

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1827225

Title:
  AppVeyor mingw builds broken (claiming missing epicsTempFile.obj)

Status in EPICS Base:
  Fix Committed
Status in EPICS Base 3.15 series:
  Fix Committed
Status in EPICS Base 7.0 series:
  Fix Committed

Bug description:
  It looks like the epicsTempName() commit (6201d37 * 3.15) broke the
  mingw builds.

  E.g. on AppVeyor

  mingw32-make[4]: Leaving directory 'C:/projects/epics-base/modules/libcom/src/O.win32-x86-mingw'
  mingw32-make[4]: *** No rule to make target 'epicsTempFile.obj', needed by 'e_flex.exe'.  Stop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1827225/+subscriptions

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System