EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
<== Date ==> <== Thread ==>

Subject: RE: Fix for building 3.15.4 on windows-x64-static
From: Mark Rivers <[email protected]>
To: "'Ralph Lange'" <[email protected]>, "'EPICS core-talk'" <[email protected]>
Date: Thu, 8 Sep 2016 14:20:45 +0000
Searching for the presence of "Visual Studio 10.0" in the PATH environment variable might work.  I don't know if the problem exists in versions of Visual Studio earlier than 2010.  Are those supported by EPICS base 3.15.4 anyway?

> Is your fix necessary for SHARED_LIBRARIES=NO or STATIC_BUILD=YES? Or  both, or any?

I believe it is only necessary for SHARED_LIBRARIES=NO.  That was definitely true before I removed the optimization disabling from src/LibCom/calc/calcPerform.c.  I need to test that dynamic builds still work after that change, but I suspect they will.  I will test that today.

Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ralph Lange
Sent: Thursday, September 08, 2016 9:05 AM
To: 'EPICS core-talk'
Subject: Re: Fix for building 3.15.4 on windows-x64-static

On 08/09/2016 14:49, Mark Rivers wrote:
> Running "cl" with no arguments will produce output like this:
>
> *******************************
> J:\epics\devel-3.15>cl
> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> usage: cl [ option... ] filename... [ /link linkoption... ]
>
> *******************************
>
> I think that output could be parsed to determine the compiler version, but I don't know how to do that.  "16.xx.xxxxx.xx for 64" is the string we want to detect for VS 2010.


Interesting. I was actually thinking more along the lines of checking 
for the presence of environment variables like %VS120COMNTOOLS% (for VS 
12.0 = 2013) or %VS100COMNTOOLS% (for VS 10.0 = 2010).
Your idea would also get the architecture, but make should know that 
already.
Is your fix necessary for SHARED_LIBRARIES=NO or STATIC_BUILD=YES? Or 
both, or any?

~Ralph



Replies:
Re: Fix for building 3.15.4 on windows-x64-static Andrew Johnson
References:
Fix for building 3.15.4 on windows-x64-static Mark Rivers
RE: Fix for building 3.15.4 on windows-x64-static Mark Rivers
Re: Fix for building 3.15.4 on windows-x64-static Ralph Lange
RE: Fix for building 3.15.4 on windows-x64-static Mark Rivers
Re: Fix for building 3.15.4 on windows-x64-static Ralph Lange

Navigate by Date:
Prev: Re: Fix for building 3.15.4 on windows-x64-static Ralph Lange
Next: Errors when running "make -sj clean" on windows-x64 in top-level of pvPackageCPP Mark Rivers
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
Navigate by Thread:
Prev: Re: Fix for building 3.15.4 on windows-x64-static Ralph Lange
Next: Re: Fix for building 3.15.4 on windows-x64-static Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
ANJ, 08 Sep 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·