Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Thu, 8 Sep 2016 16:26:41 +0000

It seems to me there are 4 ways to solve the problem:

1) The existing 3.15.4. solution which is to set HOST_OPT=NO.  This solution is bad because it sets /MTd flag,  leading to different versions of the C runtime library from what is expected.  Note that the existing solution also has a #pragma optimize() in calcPerform.c but not in online_notify.c, so it is not consistent.  When was the #pragma optimize() added to calcPerform.c, and what is the commit comment? Why was the same thing not done for online_notify.c?

2) The solution I proposed yesterday.  As in the existing solution, this is in the CONFIG_SITE file, only for 64-bit static builds.  It is better than the existing solution because it only removes the -GL flag, and leaves other optimizations enabled.  It is clean because it requires no modification of any source code files, except removing the #pragma from calcPerform.c which is nice but not necessary.  Modifying calcPerform.c removes the warning messages that are generated because of the #pragma optimize():

" base-3.15.4\src\libcom\calc\calcperform.c(47) warning C4748: /GS can not protect parameters and local variables from local buffer overrun because optimizations are disabled in function"

3) Modify the Makefile in each directory that has a problem.  This has the advantage of not modifying the source code, yet allows being specific to a particular source file.  Disadvantages:
 - By redefining OPT_CFLAGS_YES or OPT_CXXFLAGS_YES these may be specific to a particular version of base.  
  - It would require some additional changes to base to allow only doing this for Visual Studio 2010.    
  - Since we don't know what triggers the compiler error small changes to a source file may introduce the problem into a file that previously compiled OK.  This may be done by someone who is not testing on VS 2010 with 64-bit static builds, and so may not be discovered until it is too late.  The Makefile would then need to be modified.

4) Modify each source code file that has the problem to use #pragma optimize().  
  Disadvantages:
     - Requires changing 2  files in base, and at least 5 files in motor, perhaps many more, and perhaps more files in synApps that have not yet been tested because of the errors in motor.
     - All that really needs to be done is to disable program-wide optimization (/GL flag), but I cannot find a #pragma to do this.  This means that local optimization must be disabled, which results in the following warning every time that function is linked into a program:
"warning C4748: /GS can not protect parameters and local variables from local buffer overrun because optimizations are disabled in function"
    - How do we only disable optimization for 3.15, not 3.14?  
   - Since we don't know what triggers the compiler error small changes to a source file may introduce the problem into a file that previously compiled OK.  This may be done by someone who is not testing on VS 2010 with 64-bit static builds, and so may not be discovered until it is too late.

On balance I like solution 2.  It modifies only a single file (except removing the #pragma from calcPerform.c which is nice but not necessary), and appears to be robust against future modifications to source files.  But I'm open to persuasion!

Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Andrew Johnson
Sent: Thursday, September 08, 2016 10:34 AM
To: [email protected]
Subject: Re: Fix for building 3.15.4 on windows-x64-static

On 09/08/2016 09:20 AM, Mark Rivers wrote:
> Searching for the presence of "Visual Studio 10.0" in the PATH
> environment variable might work.

If the build system really needs to know which compiler version it's
using I would much rather we have the user tell it that in their
CONFIG_SITE.Common.win* file(s). The build system has to run any kind of
per-compiler test every time it reads a Makefile, and calling out to a
Perl script to do this kind of test every time is probably going to slow
the build measurably.

On the other hand doing this kind of thing using the pre-processor and a
#pragma optimize() setting is fast and localized, so I would much prefer
that we stick with that solution if it can do what we need. You can tell
whether you're building a dynamic binary there by the presence of the
EPICS_BUILD_DLL macro.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System