RE: Unable to build support modules on Windows, with base 3.15.2

["Heesterman, Peter J" <Peter.Heesterman@ccfe.ac.uk>]

Hi Mark,

 

I have seq 2.1.15 (I’m aware there are newer versions).

 

OK, here’s what it is:

This seq version appears to need two make passes to build to successful completion - this is the case whether 1, or more, cores are being used.

I never noticed that before.

 

Before building Asyn, I was careful to clean and re-build its dependencies, with single core use.

But once only, and I had overlooked the seq build fail.

 

So you’re right, the error in Asyn is just a consequence of that.

 

Thanks,

 

Peter.

 

 

From: Mark Rivers [mailto:rivers@cars.uchicago.edu]
Sent: 29 October 2015 18:19
To: Heesterman, Peter J; tech-talk@aps.anl.gov
Subject: RE: Unable to build support modules on Windows, with base 3.15.2

 

Hi Peter,

 

What version of seq are you building?  That is failing with this error:

 

'..' is not recognized as an internal or external command, operable program or batch file.

 

Your build error in asyn is simply because seq has not been built yet, so it does not know how to compile the SNL code.

 

Mark

 

 

 

From: Heesterman, Peter J [mailto:Peter.Heesterman@ccfe.ac.uk]
Sent: Thursday, October 29, 2015 1:11 PM
To: Mark Rivers; tech-talk@aps.anl.gov
Subject: RE: Unable to build support modules on Windows, with base 3.15.2

 

Hi Mark,

 

I have 4 cores on my (somewhat elderly) PC.

 

So I have built using –j4.

( I get near 100% CPU consumption b.t.w., and substantially increased build speed.)

 

I haven’t seen the race condition (or the anomalous screen output), but I do get build failure, see attached.

(base 3.15.2 built OK.)

 

Thanks,

 

Peter.

 

 

From: Mark Rivers [mailto:rivers@cars.uchicago.edu]
Sent: 29 October 2015 17:09
To: Heesterman, Peter J; tech-talk@aps.anl.gov
Subject: RE: Unable to build support modules on Windows, with base 3.15.2

 

I have seen the race condition you describe with "make -j" when using make 4.1 and base 3.15.2. 

 

However, it works for me if I do “make –j8” rather than “make –j”.  –j8 limits to 8 parallel threads, compared to no limit with –j.

 

I posted a message to tech-talk summarizing my experience building 3.15.2-rc1 in May 2015.

http://www.aps.anl.gov/epics/tech-talk/2015/msg00886.php

 

This was the summary of conclusions with parallel builds on Windows in that message:

-    - make 3.81 does not work properly with –jN, but it does work properly with –j (unlimited threads).

-    - make 3.81 and 4.1 both work fine building 3.14.12.5 either locally or remotely on a Linux file server with –sj (unlimited threads).

-    - make 3.81 and 4.1 both frequently hang up when building 3.15.2-rc1 locally with –sj.  4.1 appears to with OK with –sj8.

-    - make 3.81 and 4.1 both fail 100% of the time when building 3.15.2-rc-1 remotely with –sj.  This does NOT happen with 3.14.12.5. Note that this cannot be because the all 8 cores are 100% busy, because they are never more than about 40% busy.  The build is completely I/O bound when building remotely, but –sj still hangs.

-   - 3.15.2-rc1 takes 1.5 to 2 times longer to build than 3.14.12.5.

 

Mark

 

-----Original Message-----
From: Heesterman, Peter J [mailto:Peter.Heesterman@ccfe.ac.uk]
Sent: Thursday, October 29, 2015 11:37 AM
To: Mark Rivers; tech-talk@aps.anl.gov
Subject: RE: Unable to build support modules on Windows, with base 3.15.2

 

Hi Mark,

 

Just to let you know that, while I have no problems building single-core with Make 4.1, make -j does not work for me on Windows.

 

Sometimes, the build process locks up in a race condition (consuming 100% of one core).

Sometimes, the build process delivers unexpected error messages.

Sometimes, the textual output to stdout/stderr is corrupted and incomprehensible (but this hasn't occurred while output was re-directed to a file, screen shot attached).

 

See the attached for examples I was able to capture.

 

Thanks,

 

Peter.

 

-----Original Message-----

From: Mark Rivers [mailto:rivers@cars.uchicago.edu]

Sent: 17 September 2015 18:54

To: Heesterman, Peter J; 'Bob Soliday'; tech-talk@aps.anl.gov

Subject: RE: Unable to build support modules on Windows, with base 3.15.2

 

Note that this EPICS Web page that describes how to build on Windows:

 

http://www.aps.anl.gov/epics/base/win32.php

 

It says:

"GNU Make: The GnuWin version that we used to suggest works OK for serial builds and versions of Base up to 3.15.1, but I now recommend using my 64-bit executable of Make 4.1 which also supports make -j for parallel builds."

 

So it explicitly says that the GunWin version of make (3.81) only works up to base 3.15.1.  You are building 3.15.2, for which you need to use Make 4.1 and that Web page provides a link to a tar file containing it.

 

Mark

 

 

 

-----Original Message-----

From: Heesterman, Peter J [mailto:Peter.Heesterman@ccfe.ac.uk]

Sent: Thursday, September 17, 2015 8:53 AM

To: 'Bob Soliday'; tech-talk@aps.anl.gov; Mark Rivers

Subject: RE: Unable to build support modules on Windows, with base 3.15.2

 

Hi Bob, Mark,

 

I was running gnumake 3.81 (which seems to be the most recent binary-installable version from http://gnuwin32.sourceforge.net/packages/make.htm?).

 

I downloaded make.exe (only) from http://www.equation.com/servlet/equation.cmd?fa=make and replaced (re-named) the existing make.exe.

(Don't think this is the 'proper' install process...?)

 

Now I'm able to build normally.

 

Many thanks,

 

Peter.

 

-----Original Message-----

From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Bob Soliday

Sent: 16 September 2015 19:32

To: tech-talk@aps.anl.gov

Subject: Re: Unable to build support modules on Windows, with base 3.15.2

 

What version of gnumake are you using on Windows? When I use 3.81 I get similar errors compiling my code in extensions. When I switch to 4.1 the errors disappear.

 

On 09/16/2015 01:22 PM, Mark Rivers wrote:

> Do these files optionally included from asyn/configure/RELEASE exist and contain anything?

> 

> -include $(TOP)/../configure/SUPPORT.$(EPICS_HOST_ARCH)

> -include $(TOP)/../configure/EPICS_BASE.$(EPICS_HOST_ARCH)

> 

> Where $(EPICS_HOST_ARCH) is probably win32-x86-static for the builds you have been doing.

> 

> Mark

> 

> -----Original Message-----

> From: Heesterman, Peter J [mailto:Peter.Heesterman@ccfe.ac.uk]

> Sent: Wednesday, September 16, 2015 1:19 PM

> To: Mark Rivers; 'Jani Hakala'

> Cc: EPICS Tech-Talk (tech-talk@aps.anl.gov)

> Subject: RE: Unable to build support modules on Windows, with base

> 3.15.2

> 

> Hi Mark,

> 

>>> modified any of the files in base/configure/os?

> No. I've checked carefully.

> 

> The RELEASE file is attached (as been fiddling with D:'s and slashes).

> 

> Which set are you referring to?

> Do you mean setting the path to perl, called from win32.bat?

> 

> D:\EPICS>REM   --------------- ActiveState perl -------------------

> 

> D:\EPICS>set

> PATH=C:\Perl\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\SYSTEM32\Wb

> em

> 

> Cheers,

> 

> Peter.

> 

> 

> -----Original Message-----

> From: Mark Rivers [mailto:rivers@cars.uchicago.edu]

> Sent: 16 September 2015 18:54

> To: Heesterman, Peter J; 'Jani Hakala'

> Cc: EPICS Tech-Talk (tech-talk@aps.anl.gov)

> Subject: RE: Unable to build support modules on Windows, with base

> 3.15.2

> 

> Strange, it is putting the current path in front of the path to the perl script in base.

> 

> Have you modified any of the files in base/configure/os?

> 

> Send the contents of asyn/configure/RELEASE and the output of the "set" command.

> 

> Mark

> 

> 

> -----Original Message-----

> From: Heesterman, Peter J [mailto:Peter.Heesterman@ccfe.ac.uk]

> Sent: Wednesday, September 16, 2015 12:21 PM

> To: Mark Rivers; 'Jani Hakala'

> Cc: EPICS Tech-Talk (tech-talk@aps.anl.gov)

> Subject: RE: Unable to build support modules on Windows, with base

> 3.15.2

> 

> Hi Mark,

> 

> That's a combination that I've tried, with the result attached.

> 

> Cheers,

> 

> Peter.

> 

> -----Original Message-----

> From: Mark Rivers [mailto:rivers@cars.uchicago.edu]

> Sent: 16 September 2015 17:45

> To: Heesterman, Peter J; 'Jani Hakala'

> Cc: EPICS Tech-Talk (tech-talk@aps.anl.gov)

> Subject: RE: Unable to build support modules on Windows, with base

> 3.15.2

> 

> I define EPICS_BASE like this:

> EPICS_BASE=H:/epics/base-3.14.12.5

> 

> I use a drive letter and forward slashes.

> 

> Mark

> 

> 

> -----Original Message-----

> From: Heesterman, Peter J [mailto:Peter.Heesterman@ccfe.ac.uk]

> Sent: Wednesday, September 16, 2015 11:36 AM

> To: Mark Rivers; 'Jani Hakala'

> Cc: EPICS Tech-Talk (tech-talk@aps.anl.gov)

> Subject: RE: Unable to build support modules on Windows, with base

> 3.15.2

> 

> Hi Mark, Jani,

> 

> Thank you for your responses.

> 

> FYI my build directory structure has:

> D:\EPICS

>             Base

>             Support

>                             Seq

>                             Asyn

>                             ...

> 

> I have configured RELEASE in these modules as:

>             EPICS_BASE=\EPICS\base

> 

> I have also experimented with (explicitly) D:\EPICS\base - I prefer to avoid doing so, as the C: drive could be used.

> I have also experimented with various combinations of the slash character.

> None of this made any difference.

> 

> You are correct, perl -CSD \EPICS\base/bin/win32-x86-static/makeMakefile.pl ... is the correct and expected output.

> I have no idea why D:/EPICS/support/asyn/configure/ has been prepended - it doesn't make any sense.

> 

> Also, why are the directories '.' and '..' being compiled as perl scripts, resulting in 'permission denied'?

> BTW, I have not set any unusual permissions - (Everyone - Read only), (Administrators, system and myself, full control).

> 

> Cheers,

> 

> Peter.

> 

> 

> 

> -----Original Message-----

> From: Mark Rivers [mailto:rivers@cars.uchicago.edu]

> Sent: 15 September 2015 21:43

> To: 'Jani Hakala'; Heesterman, Peter J

> Cc: EPICS Tech-Talk (tech-talk@aps.anl.gov)

> Subject: RE: Unable to build support modules on Windows, with base

> 3.15.2

> 

> Hi Peter,

> 

> I agree with Jani.

> 

> This is what you are getting:

> 

> make[1]: Entering directory `D:/EPICS/support/asyn/configure'

> perl -CSD D:/EPICS/support/asyn/configure/\EPICS\base/bin/win32-x86-static/makeMakefile.pl O.win32-x86-static ../..

> 

> This is what I get:

> 

> make[1]: Entering directory 'C:/EPICS/Support-3-15/asyn-R4-26/configure'

> perl -CSD C:/EPICS/base-3.15.2/bin/windows-x64/makeMakefile.pl O.windows-x64 ../..

> 

> For some reason for you it is putting the current path in front of the path to the makeMakefile.pl script in EPICS base.

> 

> How have you defined EPICS_BASE in asyn/configure/RELEASE?

> 

> Mark

> 

> 

> -----Original Message-----

> From: tech-talk-bounces@aps.anl.gov

> [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Jani Hakala

> Sent: Tuesday, September 15, 2015 3:03 PM

> To: Heesterman, Peter J

> Cc: EPICS Tech-Talk (tech-talk@aps.anl.gov)

> Subject: Re: Unable to build support modules on Windows, with base

> 3.15.2

> 

> "Heesterman, Peter J" <Peter.Heesterman@ccfe.ac.uk> writes:

> 

>> Hi,

>> 

>> I just downloaded EPICS base 3.15.2, superseding previous 3.15.1.  I

>> am experiencing a problem building any of the support modules, while

>> using the make file build.  (There is no problem building base 3.15.2

>> itself, however.)

>> 

>> I've built all the same code successfully on Linux, while using

>> 3.15.2.

>> 

>> See attached, these are examples when trying to build Asyn or Seq,

>> but this applies to all modules I've looked at, and to different

>> build configurations I've attempted.  It all built OK when using 3.15.1.

>> 

>> What could I be missing?

>> 

> This doesn't look so good

> 

>      perl -CSD D:/EPICS/support/asyn/configure/\EPICS\base/bin/win32-x86-static/makeMakefile.pl O.win32-x86-static ../..

> 

> i.e. that "\EPICS\base" part.

> 

> I would check the contents of asyn/configure/RELEASE for definitions of SUPPORT and EPICS_BASE or the contents of environment variables.

> 

> Jani Hakala

> 

> 

> 

>