EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>
Subject: Re: windows build/test failures
From: Andrew Johnson <[email protected]>
To: Michael Davidsaver <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>
Date: Mon, 8 May 2017 10:37:24 -0500 
Freddie helped me develop this fix some time back (but after the int64
branch was created) so it was already in place in 2 other source files
and I just had to copy it across. Our version handles multiple MinGW
versions too.

I'm wondering whether we should move the code (which looks like this)

> #ifdef _WIN32
> #if (defined(_MSC_VER) && _MSC_VER < 1900) || \
>     (defined(_MINGW) && defined(_TWO_DIGIT_EXPONENT))
>     _set_output_format(_TWO_DIGIT_EXPONENT);
> #endif
> #endif

into libCom somewhere, but I'm not sure where since it's a run-time
call; testPlan() would work fine for existing uses which are all in test
programs, but IOCs running on Windows will still get 3-digit exponents —
maybe that isn't a problem. Anyone against that idea?

- Andrew

On 05/07/2017 09:03 AM, Michael Davidsaver wrote:
> Hi Freddie,
> 
> Seems like Andrew had the same thought.
> 
> https://github.com/epics-base/epics-base/commit/fd583ac59413021b0a142579212b27a4e4cad2fb
> 
> At this point all the issues I'm aware of are addressed.
> 
> Michael
> 
> 
> On 05/06/2017 01:50 PM, [email protected] wrote:
>> Hi Michael,
>>
>> Visual Studio C runtime used 3 digit exponents by default prior to VS 2015, but you can change this behaviour.
>>  
>> https://msdn.microsoft.com/en-us/library/0fatw238(v=vs.120).aspx
>>
>> in VS 2015 the above function is withdrawn and 2 digit exponents are used, so you'd need to protect any usage of this function with something like
>>
>> #if defined(_WIN32)  && defined(_MSC_VER) && (_MSC_VER < 1900)
>>
>> Regards,
>>
>> Freddie
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of Michael Davidsaver
>> Sent: 06 May 2017 02:02
>> To: Andrew Johnson; Ralph Lange; EPICS core-talk
>> Subject: Re: windows build/test failures
>>
>> the dllimport/export issue is fixed.  My mistake in including epicsExport.h in the wrong place.
>>
>> The test failure is at least diagnosed:
>>
>>> not ok 739 - cvtFloatToString(1e+08, 6) == 12 (13) -> "1.000000e+008"
>>>     ok 739 - cvtFloatToString(1e+08, 6) == 12 (12) -> "1.000000e+08"
>>
>> An extra zero in the exponent.  I don't see this as a blocker for a pre-release.
>>
>> I also fixed an issue with the filterTestHarness and filter registration.  The RTEMS tests, individual and test harnesses, now pass for me with qemu.
>>
>>
>> On 05/05/2017 08:43 AM, Michael Davidsaver wrote:
>>> After I merged the link-support and int64 code last night two windows 
>>> issues turned up.  Some assistance would be appreciated as I can't 
>>> reproduce these myself.
>>>
>>>
>>> One is a dll import/export error which I can not make sense of as 
>>> dbFastGetConvertRoutine should be marked with dllimport in this file, 
>>> but doesn't appear to be (to my limited knowledge):
>>>
>>>> link -nologo -subsystem:windows -dll -LTCG -incremental:no -opt:ref -release -version:3.16      -out:dbTestIoc.dll -implib:dbTestIoc.lib        arrRecord.obj xRecord.obj dbLinkdset.obj xLink.obj devx.obj jlinkz.obj      ../../../../../lib/win32-x86/dbCore.lib  ../../../../../lib/win32-x86/ca.lib  ../../../../../lib/win32-x86/Com.lib  
>>>>    Creating library dbTestIoc.lib and object dbTestIoc.exp jlinkz.obj 
>>>> : error LNK2001: unresolved external symbol _dbFastGetConvertRoutine 
>>>> jlinkz.obj : error LNK2001: unresolved external symbol 
>>>> _dbFastPutConvertRoutine dbTestIoc.dll : fatal error LNK1120: 2 
>>>> unresolved externals
>>>
>>> https://jenkins.aps.anl.gov/job/epics-base-3.16-win32/106/console
>>>
>>>
>>> The other is a test failure.  It doesn't print enough for me to be 
>>> able to say what the issue is.
>>>
>>>> src/libCom/test/O.windows-x64-static/cvtFastTest.tap .............. 
>>>> not ok 724 - cvtFloatToString(1e+08, 1) == 7 not ok 727 - 
>>>> cvtFloatToString(1e+08, 2) == 8 not ok 730 - cvtFloatToString(1e+08, 
>>>> 3) == 9 not ok 733 - cvtFloatToString(1e+08, 4) == 10 not ok 736 - 
>>>> cvtFloatToString(1e+08, 5) == 11 not ok 739 - cvtFloatToString(1e+08, 
>>>> 6) == 12 Failed 6/1062 subtests
>>>
>>> https://jenkins.aps.anl.gov/job/epics-base-3.16-win64s-test/69/console
>>>
>>
> 

-- 
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
References:
windows build/test failures Michael Davidsaver
Re: windows build/test failures Michael Davidsaver
RE: windows build/test failures freddie.akeroyd
Re: windows build/test failures Michael Davidsaver
Navigate by Date:
Prev: Re: windows build/test failures Michael Davidsaver
Next: Re: Update CAJ to catch empty PV name Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: windows build/test failures Michael Davidsaver
Next: Problem with the iptables DNAT filter Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024