I don't really understand what I'm seeing here. Andrew or Mark,
can one of you open a ticket for this build failure?
https://bugs.launchpad.net/epics-base/+filebug
On 12/27/2017 04:46 PM, Mark Rivers wrote:
> Building EPICS base 7.0.1.1 with VS 2015, windows-x64-static failed as follows:
>
>
>
> forceBadAllocException.cpp
>
> process_begin: CreateProcess(NULL, rc -l 0x409 -I. -I../O.Common -I. -I../../src/osi/compiler/msvc -I../../src/osi/compiler/default -I. -I../../src/osi/os/WIN32 -I../../src/osi/os/
>
> default -I.. -I../../src/as -I../../src/bucketLib -I../../src/calc -I../../src/cvtFast -I../../src/cppStd -I../../src/cxxTemplates -I../../src/dbmf -I../../src/ellLib -I../../src/e
>
> nv -I../../src/error -I../../src/fdmgr -I../../src/flex -I../../src/freeList -I../../src/gpHash -I../../src/iocsh -I../../src/log -I../../src/macLib -I../../src/misc -I../../src/os
>
> i -I../../src/pool -I../../src/ring -I../../src/taskwd -I../../src/timer -I../../src/yacc -I../../src/yacc -I../../src/yajl -IH:/epics-devel/base-7.0.1/include/compiler/msvc -IH:/e
>
> pics-devel/base-7.0.1/include/os/WIN32 -IH:/epics-devel/base-7.0.1/include -IH:/epics-devel/base-7.0.1/include/compiler/msvc -IH:/epics-devel/base-7.0.1/include/os/WIN32 -IH:/epics
>
> -devel/base-7.0.1/include -fo Com.res ../Com.rc, ...) failed.
>
> make (e=2): The system cannot find the file specified.
>
> H:/epics-devel/base-7.0.1/configure/RULES_BUILD:242: recipe for target 'Com.res' failed
>
> make[4]: *** [Com.res] Error 2
>
> make[4]: *** Waiting for unfinished jobs....
>
> iocLogServer.c
>
> ../../src/log/iocLogServer.c(418): warning C4244: 'function': conversion from 'SOCKET' to 'int', possible loss of data
>
> H:/epics-devel/base-7.0.1/configure/RULES_ARCHS:58: recipe for target 'install.windows-x64-static-vs2015' failed
>
> make[3]: *** [install.windows-x64-static-vs2015] Error 2
>
> H:/epics-devel/base-7.0.1/configure/RULES_DIRS:84: recipe for target 'src.install' failed
>
> make[2]: *** [src.install] Error 2
>
> ../configure/RULES_DIRS:84: recipe for target 'libcom.install' failed
>
> make[1]: *** [libcom.install] Error 2
>
> configure/RULES_DIRS:84: recipe for target 'modules.install' failed
>
> make: *** [modules.install] Error 2
>
>
>
> Any idea what is wrong?
>
>
>
> Thanks,
>
> Mark
>
>
>
>
>
> *From:*Mark Rivers
> *Sent:* Wednesday, December 27, 2017 3:15 PM
> *To:* 'Andrew Johnson'; [email protected]
> *Subject:* RE: Problem building example application on windows-x64
>
>
>
> OK, that patch let me get the example application to compile.
>
>
>
> However, there are problems when running it. The behavior I see is different on windows-x64 and windows-x64-static.
>
>
>
> - On windows-x64 the IOC application runs OK but when I try to exit the application I get the error I reported in my first message today, i.e. epicsSocketDestroy errors. ^C will not kill the IOC application, I need to use the Task Manager. This is a serious problem, and as I said earlier it affects other IOCs such as simDetector.
>
>
>
> J:\epics\devel\example\iocBoot\ioctest>..\..\bin\windows-x64\test.exe st.cmd
>
> #!../../bin/windows-x64-static/test
>
> < envPaths
>
> epicsEnvSet("IOC","ioctest")
>
> epicsEnvSet("TOP","J:/epics/devel/example")
>
> epicsEnvSet("EPICS_BASE","H:/epics-devel/base-7.0.1")
>
> cd "J:/epics/devel/example"
>
> ## Register all support components
>
> dbLoadDatabase "dbd/test.dbd"
>
> test_registerRecordDeviceDriver pdbbase
>
> ## Load record instances
>
> dbLoadTemplate "db/user.substitutions"
>
> dbLoadRecords "db/testVersion.db", "user=rivers"
>
> dbLoadRecords "db/dbSubExample.db", "user=rivers"
>
> #var mySubDebug 1
>
> #traceIocInit
>
> cd "J:/epics/devel/example/iocBoot/ioctest"
>
> iocInit
>
> Starting iocInit
>
> ############################################################################
>
> ## EPICS R7.0.1.1
>
> ## EPICS Base built Dec 16 2017
>
> ############################################################################
>
> iocRun: All initialization complete
>
> 2017-12-27T14:52:54.595 No broadcast addresses found or specified - empty address list!
>
> ## Start any sequence programs
>
> #seq sncExample, "user=rivers"
>
> epics>
>
> epics>
>
> epics>
>
> epics>
>
> epics> exit
>
> epicsSocketDestroy: failed to close a socket because "WINSOCK Error 10093"
>
> 2017-12-27T14:53:16.250 Receive thread for UDP socket 0.0.0.0:0 has not exited.
>
> epicsSocketDestroy: failed to close a socket because "WINSOCK Error 10093"
>
> 2017-12-27T14:53:21.296 Receive thread for UDP socket 164.54.160.31:5076 has not exited.
>
> epicsSocketDestroy: failed to close a socket because "WINSOCK Error 10093"
>
> 2017-12-27T14:53:26.333 Receive thread for UDP socket 0.0.0.0:5076 has not exited.
>
> epicsSocketDestroy: failed to close a socket because "WINSOCK Error 10093"
>
>
>
>
>
> On windows-x64-static the IOC crashes immediately, without even starting to execute the st.cmd file:
>
>
>
> J:\epics\devel\example>make -sj clean uninstall
>
>
>
> J:\epics\devel\example>make -sj
>
> devXxxSoft.c
>
> xxxRecord.c
>
> testHello.c
>
> dbSubExample.c
>
> devtestVersion.c
>
> initTrace.c
>
> testMain.cpp
>
> test_registerRecordDeviceDriver.cpp
>
> ../devtestVersion.c(27) : warning C4267: '=' : conversion from 'size_t' to 'epicsUInt32', possible loss of data
>
> ../xxxRecord.c(211) : warning C4244: '=' : conversion from 'epicsFloat64' to 'float', possible loss of data
>
> ../xxxRecord.c(211) : warning C4244: '=' : conversion from 'epicsFloat64' to 'float', possible loss of data
>
> Appending initTrace.obj
>
> Appending testHello.obj
>
> Appending devtestVersion.obj
>
> Appending dbSubExample.obj
>
> Appending devXxxSoft.obj
>
> Appending xxxRecord.obj
>
>
>
> J:\epics\devel\example>cd iocBoot\ioctest
>
>
>
> J:\epics\devel\example\iocBoot\ioctest>..\..\bin\windows-x64-static\test.exe st.cmd
>
>
>
> At that point Windows pops up a dialog box telling me that test.exe has crashed. Opening the Visual Studio debugger tells me that it is an access violation on address 0.
>
>
>
> Is there a test in EPICS base that instantiates the example IOC?
>
>
>
> Mark
>
>
>
>
>
>> -----Original Message-----
>
>> From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf
>
>> Of Andrew Johnson
>
>> Sent: Wednesday, December 27, 2017 1:04 PM
>
>> To: [email protected] <mailto:[email protected]>
>
>> Subject: Re: Problem building example application on windows-x64
>
>>
>
>> Hi Mark,
>
>>
>
>> On 12/27/2017 12:05 PM, Mark Rivers wrote:
>
>> > I just did this again, but running makeBaseApp.pl with Windows rather
>
>> > than Linux. I get the same problem. It looks like the problem is that
>
>> > testVersion.h is changing because the timestamp is incrementing by 1
>
>> > second between the time it is created and checked?
>
>>
>
>> I agree; it seems to be a problem with the genVersionHeader.pl script
>
>> that Michael added in 3.16.1 and the dependency rules. This is the
>
>> relevant part of your build log:
>
>>
>
>> > perl -CSD H:/epics-devel/base-7.0.1/bin/windows-x64/genVersionHeader.pl
>
>> > -t ../../.. -N testVERSION -V "" ../O.Common/testVersion.h
>
>> >
>
>> > Updating VCS header ../O.Common/testVersion.h
>
>> > testVERSION = "2017-12-27T11:39:33"
>
>> >
>
>> > perl -CSD H:/epics-devel/base-7.0.1/bin/windows-x64/mkmf.pl -m
>
>> > devtestVersion.d -I. -I../O.Common -I. -I. -I..
>
>> > -I../../../include/compiler/msvc -I../../../include/os/WIN32
>
>> > -I../../../include -IH:/epics-devel/base-7.0.1/include/compiler/msvc
>
>> > -IH:/epics-devel/base-7.0.1/include/os/WIN32
>
>> > -IH:/epics-devel/base-7.0.1/include devtestVersion.obj
>
>> > ../devtestVersion.c
>
>> >
>
>> > perl -CSD H:/epics-devel/base-7.0.1/bin/windows-x64/genVersionHeader.pl
>
>> > -t ../../.. -N testVERSION -V "" ../O.Common/testVersion.h
>
>> >
>
>> > Updating VCS header ../O.Common/testVersion.h
>
>> > testVERSION = "2017-12-27T11:39:34"
>
>> >
>
>> > perl -CSD H:/epics-devel/base-7.0.1/bin/windows-x64/mkmf.pl -m
>
>> > devtestVersion.d -I. -I../O.Common -I. -I. -I..
>
>> > -I../../../include/compiler/msvc -I../../../include/os/WIN32
>
>> > -I../../../include -IH:/epics-devel/base-7.0.1/include/compiler/msvc
>
>> > -IH:/epics-devel/base-7.0.1/include/os/WIN32
>
>> > -IH:/epics-devel/base-7.0.1/include devtestVersion.obj
>
>> > ../devtestVersion.c
>
>> >
>
>> > perl -CSD H:/epics-devel/base-7.0.1/bin/windows-x64/genVersionHeader.pl
>
>> > -t ../../.. -N testVERSION -V "" ../O.Common/testVersion.h
>
>> >
>
>> > Updating VCS header ../O.Common/testVersion.h
>
>> > testVERSION = "2017-12-27T11:39:35"
>
>>
>
>> whereas on Linux I get:
>
>>
>
>> > perl -CSD /home/phoebus/ANJ/epics/base/7.0/bin/linux-x86_64/genVersionHeader.pl
>
>> > -t ../../.. -N testVERSION -V "" ../O.Common/testVersion.h
>
>> >
>
>> > Updating VCS header ../O.Common/testVersion.h
>
>> > testVERSION = "2017-12-27T12:08:23-0600"
>
>> >
>
>> > /usr/bin/gcc -D_GNU_SOURCE -D_DEFAULT_SOURCE -
>
>> DUSE_TYPED_RSET
>
>> > -D_X86_64_ -DUNIX -Dlinux -O3 -g -Wall -mtune=generic -m64
>
>> > -Wpointer-arith -fvisibility=hidden -fPIC -I. -I../O.Common -I. -I. -I..
>
>> > -I../../../include/compiler/gcc -I../../../include/os/Linux
>
>> -I../../../include
>
>> > -I/home/phoebus/ANJ/epics/base/7.0/include/compiler/gcc
>
>> > -I/home/phoebus/ANJ/epics/base/7.0/include/os/Linux
>
>> > -I/home/phoebus/ANJ/epics/base/7.0/include -MM -MF devtestVersion.d
>
>> > ../devtestVersion.c
>
>> >
>
>> > perl -CSD /home/phoebus/ANJ/epics/base/7.0/bin/linux-x86_64/genVersionHeader.pl
>
>> > -t ../../.. -N testVERSION -V "" ../O.Common/testVersion.h
>
>> >
>
>> > Keeping VCS header ../O.Common/testVersion.h
>
>> > testVERSION = "2017-12-27T12:08:23-0600"
>
>>
>
>> There seems to be a mismatch between the assumptions that script makes
>
>> about file-system modification times and how GNUmake works on Windows.
>
>> The old DOS FAT file-system had a time-stamp granularity of 2 seconds
>
>> and that has resulted in some workarounds being added to GNUmake on
>
>> Windows, e.g. see http://www.delorie.com/djgpp/v2faq/faq22_18.html or
>
>> there may be a delay added at the end of the phase-1 run before GNUmake
>
>> re-reads the Makefiles — that might explain what's happening here.
>
>>
>
>> Michael: How about we drop the seconds field completely from the build
>
>> date/time-stamp? That should prevent this kind of problem from
>
>> recurring. It would still trigger a re-creation of the header whenever
>
>> there is a roll-over, but that should only happen once, not continuously
>
>> like Mark is seeing.
>
>>
>
>> Mark: If you want to try out that fix, edit
>
>> base-7.0/src/tools/genVersionHeader.pl and make this change:
>
>>
>
>> > diff --git a/src/tools/genVersionHeader.pl b/src/tools/genVersionHeader.pl
>
>> > index 5851ea8..8e50fec 100644
>
>> > --- a/src/tools/genVersionHeader.pl
>
>> > +++ b/src/tools/genVersionHeader.pl
>
>> > @@ -19,7 +19,7 @@ use POSIX qw(strftime);
>
>> > use strict;
>
>> >
>
>> > # RFC 8601 date+time w/ zone (eg "2014-08-29T09:42:47-0700")
>
>> > -my $tfmt = '%Y-%m-%dT%H:%M:%S';
>
>> > +my $tfmt = '%Y-%m-%dT%H:%M';
>
>> > $tfmt .= '%z' unless $^O eq 'MSWin32'; # %z returns zone name on Windows
>
>> > my $now = strftime($tfmt, localtime);
>
>> >
>
>>
>
>> - 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: Problem building example application on windows-x64 Mark Rivers
- References:
- Problem building example application on windows-x64 Mark Rivers
- RE: Problem building example application on windows-x64 Mark Rivers
- Re: Problem building example application on windows-x64 Andrew Johnson
- RE: Problem building example application on windows-x64 Mark Rivers
- RE: Problem building example application on windows-x64 Mark Rivers
- Navigate by Date:
- Prev:
Re: Problem building example application on windows-x64 Michael Davidsaver
- Next:
genVersionHeader.pl timestamp granularity (was Re: Problem building example application on windows-x64) Michael Davidsaver
- 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: Problem building example application on windows-x64 Mark Rivers
- Next:
RE: Problem building example application on windows-x64 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
2024
|