I tested with a local installation of base-3.15.2-rc1 on my Windows system.
I still saw the problem with “make –j” hanging, with make using 100% of a core. But the problem was intermittent. I don’t have a lot of statistics, but it seemed to happen perhaps
50% of the time when using “make –sj” (very little terminal output), and less frequently with “make –j” where there is a lot of terminal output.
If it hung up I was able to kill it and just start it again, so it picked up where the previous hung run had left off.
I was able to successfully build all 4 WIN32 architectures with parallel make, though sometimes having to restart it once to get it to complete.
When it hung with “make –sj” this was the last output before I killed it. Several times it hung in this same place.
Finished generating code
The performance with the local build is much faster than the remote non-parallel builds, which took 46 minutes or remote parallel builds on 220.127.116.11 which took 6 minutes.
So it was 2-3 times faster than doing a remote parallel make on 18.104.22.168.
This is GNUWin32 make 3.81.
From: Mark Rivers
Sent: Thursday, April 30, 2015 3:56 PM
To: 'Ralph Lange'; EPICS Tech-Talk
Subject: RE: Base R3.15.2-rc1 release
I just tested 3-15.2-rc1 on WIN32, and found some problems.
My setup is using a Linux file server that holds a single tree, in which I build for all architectures (Linux, WIN32, Cygwin, vxWorks, Darwin). I don’t know if that configuration
has any bearing on my results.
I found that parallel make does not work on any WIN32 architectures (win32-x86, win32-x86-static, windows-x64, windows-x64-static). The symptom is that “make” goes to using 100%
of a core at some point during the build of libCom, and no further output occurs. This was the output of “make –j” at the point where it hung building win32-x86-static:
perl -CSD H:/epics/base-3.15.2-rc1/bin/win32-x86-static/mkmf.pl -m epicsUnitTest.d -I. -I../O.Common -I. -I../../../src
/libCom/osi/compiler/msvc -I../../../src/libCom/osi/compiler/default -I. -I../../../src/libCom/osi/os/WIN32 -I../../../s
rc/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/libC
om/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../../../sr
c/libCom/yacc -I../../../src/libCom/yajl -I../../../include/compiler/msvc -I../../../include/os/WIN32 -I../../../include
"make" was using 100% of one core at this point, and nothing further happened. I had to kill it with ^C.
On base 22.214.171.124 win32-x86-static and windows-x64-static work fine with parallel make, while win32-x86 and windows-x64 do not. The failure for the archs that don’t work is an
error reporting a missing .lib file I believe.
The performance is also significantly worse, even for non-parallel make. These are times I measured today for building the win32-x86-static architecture:
126.96.36.199 parallel make 6 minutes
188.8.131.52 non-parallel make 22 minutes
3.15.2-rc-1 non-parallel make 46 minutes
So it is taking 7.5 times longer to build 3.15.2-rc1 than 184.108.40.206. This is mostly because I can use parallel make, but even non-parallel make is over twice as fast on the older
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Ralph Lange
Sent: Thursday, April 30, 2015 2:16 AM
To: EPICS Tech-Talk
Subject: Base R3.15.2-rc1 release
The (first) release candidate for the next release of the EPICS Base
3.15 series 3.15.2-rc1 is now available for download and testing. Please
read the Release Notes to see what's new in this release.
Please test - especially if you have less widespread OS/architecture
setups that you can test on - and report feedback and any problems you
encounter here on the tech-talk list.
Note that some support modules may require changes to build properly
with this release, so check with a module author to see if they have a
3.15 version available if you encounter problems.
If no major issues arise with this code, the final 3.15.2 release will
be created in the second week of May. Thanks to everyone who has
contributed towards this release, and especially to the other core
developers for all their work.