Hi Mark,
On 07/05/2016 06:51 PM, Mark Rivers wrote:
> I am trying to help someone in the UK build EPICS base 3.14.12.5 on
> Visual Studio 2015. He is using windows-x64 arch.
> So both version 19, but different minor version numbers. I am not
> sure if he installed Community Edition or something else.
From the Microsoft VC++ Blog: "MSVC Version 19.00.23918 corresponds to
Visual Studio 2015 Update 2." so he just has a slightly newer compiler.
https://blogs.msdn.microsoft.com/vcblog/2016/04/26/stay-up-to-date-with-the-visual-c-tools-on-nuget/
> This is the output on his system:
> cl /nologo /EHsc /GR -c /favor:blend /nologo /D__STDC__=0 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /Ox /GL /W3 /w44355 /MD /TP
> -I. -I..\\O.Common -I. -I.. -I..\\..\\..\\..\\include\\os\\WIN32 -I..\\..\\..\\..\\include ..\\epicsExceptionTest.cpp
> epicsExceptionTest.cpp
> ..\epicsExceptionTest.cpp(68): error C2148: total size of array must not exceed 0x7fffffff bytes
> ..\epicsExceptionTest.cpp(79): error C2148: total size of array must not exceed 0x7fffffff bytes
> ../../../../configure/RULES_BUILD:218: recipe for target 'epicsExceptionTest.obj ' failed
>
> So it appears that the command lines are identical, but his fails and
> mine works. Any idea why?
Probably due to optimizer changes in the new version, see below...
> He tried applying the patch on the 3.14.12.5 Known Problems page, but
> that should only apply to win32-x86, not windows-x64, right?
I don't see why that patch should be specific to the 32-bit target,
although I admit the wording on the Known Problems page does imply that
(I just changed it).
> Both patched and unpatched built OK for me.
From his error messages it looks like the MS optimizer is now checking
allocation sizes at compiler time. The point of that particular part of
the epicsExceptionTest.cpp program is to confirm that C++ operator new
throws a std::bad_alloc exception at runtime when it fails. In the early
days some pre-standard C++ compilers would return NULL instead, which
was not compatible with the EPICS code.
We could take a look at defeating the optimizer, but this particular
piece of code has caused several false-positive build problems recently
and already has several compiler-specific pre-processor switches in it.
I don't think the test is necessary any more, so will probably delete
that test program completely for future Base releases.
I suggest you show your user how to remove the program from the
libCom/test/Makefile build — there are 4 lines in a block that mention
epicsExceptionTest, they should all be deleted or commented out.
- 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
- Replies:
- RE: FW: EPICS Mark Rivers
- Navigate by Date:
- Prev:
Jenkins build is back to stable : epics-base-3.14-mac #98 APS Jenkins
- Next:
RE: FW: EPICS Mark Rivers
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
- Navigate by Thread:
- Prev:
Jenkins build is back to stable : epics-base-3.14-mac #98 APS Jenkins
- Next:
RE: FW: EPICS Mark Rivers
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
|