Experimental Physics and
Industrial Control System

"Wang Xiaoqiang" <[email protected]> · Fri, 21 Feb 2014 10:30:33 +0100

Hi Andrew,

Sorry this is the first time I realize the existence of these test
suits. 
I inserted a debug printout in the file "blockingSockTest.cpp"
printf("error code is %d", WSAGetLastError());
And the error code is 100093, which means WSANOTINITIALISED according to
MSDN.

So I inserted the pair osiSockAttach() and osiSockRelease 
---
/cygdrive/c/epics/base-3.14.12.4/src//libCom/test/blockingSockTest.cpp
2013-12-16 22:56:27.000000000 +0100
+++ blockingSockTest.cpp        2014-02-21 10:10:17.768207900 +0100
@@ -244,6 +244,7 @@
 MAIN(blockingSockTest)
 {
     testPlan(1);
+    osiSockAttach();

     address addr;
     memset ( (char *) & addr, 0, sizeof ( addr ) );
@@ -285,6 +286,7 @@
         testDiag("epicsSocketSystemCallInterruptMechanismQuery returned
\"%s\"",
             mechName(query));

+    osiSockRelease();
     return testDone();
 }

The same has to been done on file "epicsSockResolveTest.c".


Here is the output from "make runtests",
perl -MTest::Harness -e 'runtests @ARGV if @ARGV;' epicsUnitTestTest.t
epicsCalc
Test.t epicsAlgorithmTest.t epicsMathTest.t epicsEllTest.t
epicsEnvTest.t epicsE
rrlogTest.t epicsStdioTest.t epicsSockResolveTest.t epicsStringTest.t
epicsTimeT
est.t epicsThreadTest.t epicsThreadOnceTest.t epicsThreadPriorityTest.t
epicsThr
eadPrivateTest.t epicsExitTest.t epicsTimerTest.t ringPointerTest.t
ringBytesTes
t.t epicsEventTest.t epicsMutexTest.t epicsExceptionTest.t
macEnvExpandTest.t ma
cLibTest.t taskwdTest.t blockingSockTest.t epicsMessageQueueTest.t
epicsUnitTestTest.t ........ ok
epicsCalcTest.t ............ ok
epicsAlgorithmTest.t ....... ok
epicsMathTest.t ............ ok
epicsEllTest.t ............. ok
epicsEnvTest.t ............. ok
epicsErrlogTest.t .......... ok
epicsStdioTest.t ........... ok
epicsSockResolveTest.t ..... ok
epicsStringTest.t .......... ok
epicsTimeTest.t ............ ok
epicsThreadTest.t .......... ok
epicsThreadOnceTest.t ...... 1/11 Recursive epicsThreadOnce()
initialization
Thread recurse (00646840) can't proceed, suspending.
epicsThreadOnceTest.t ...... ok
epicsThreadPriorityTest.t .. ok
epicsThreadPrivateTest.t ... ok
epicsExitTest.t ............ ok
epicsTimerTest.t ........... ok
ringPointerTest.t .......... ok
ringBytesTest.t ............ ok
epicsEventTest.t ........... ok
epicsMutexTest.t ........... ok
epicsExceptionTest.t ....... ok
macEnvExpandTest.t ......... macLib: macro FOO is undefined (expanding
string ${
FOO})
macEnvExpandTest.t ......... 1/71 macLib: macro FOO is undefined
(expanding stri
ng ${FOO,BAR})
macLib: macro FOO is undefined (expanding string ${FOO,BAR=baz})
macLib: macro FOO is undefined (expanding string ${FOO,BAR=$(FOO)})
macLib: macro FOO is undefined (expanding string ${FOO,FOO})
macLib: string ${FOO,FOO=$(FOO)} is recursive (expanding macro FOO)
macLib: macro FOO is undefined (expanding string ${FOO,BAR=baz,FUM})
macLib: macro BAZ is undefined (expanding string ${FOO})
macLib: string ${FOO} is recursive (expanding environment variable FOO)
macLib: string ${FOO,FOO=$(FOO)} is recursive (expanding environment
variable FO
O)
macLib: string ${FOO=$(FOO)} is recursive (expanding environment
variable FOO)
macLib: string ${FOO=$(BAR),BAR=$(FOO)} is recursive (expanding
environment vari
able FOO)
macEnvExpandTest.t ......... ok
macLibTest.t ............... ok
taskwdTest.t ............... 3/8 Thread testTask2 (0062DCE8) suspended
taskwdTest.t ............... ok
blockingSockTest.t ......... ok
epicsMessageQueueTest.t .... ok
All tests successful.
Files=27, Tests=2048, 534 wallclock secs ( 0.17 usr +  0.03 sys =  0.20
CPU)
Result: PASS

Best
Xiaoqiang

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Andrew Johnson
Sent: Freitag, 21. Februar 2014 00:08
To: [email protected]
Subject: Re: Fwd: epics base with MinGW-w64

Hi Xiaoqiang,

I tried changing "if defined(_DLL)" into "if !defined(EPICS_DLL_NO)" in
shareLib.h but it does not fix all cases and breaks some builds.

With that change included and building statically, several of the
network-related test programs that come with Base fail badly for me
(type 'make runtests' in the base-3.14.12.4 top directory to run them
yourself). I tried them with both the Microsoft and MinGW compilers,
with the same results, e.g.:

> blockingSockTest.exe
> 
> A call to 'assert(this->sock != INVALID_SOCKET)'
>     by thread 'win148' failed in ..\blockingSockTest.cpp line 172.
> EPICS Release EPICS R3.14.12.4-DEV $$Date$$.
> Local time is 2014-02-20 12:52:53.543946691 Ame Please E-mail this 
> message to the author or to [email protected] Calling 
> epicsThreadSuspendSelf()

The change also breaks the shared-library builds using the Microsoft
compiler, so I can't include it in the shipped version of Base.

As Peter mentioned, a comprehensive fix has been implemented in the 3.15
development version of Base, but 3.15 has not been released for
production use yet.

- Andrew


On 02/20/2014 02:47 AM, Xiaoqiang Wang wrote:
> 
> 
> For the archive purpose, I forward this answer from Peter Heesterman.
> 
> Begin forwarded message:
> 
>> From: "Heesterman, Peter J" <[email protected]>
>> Subject: RE: epics base with MinGW-w64
>> Date: 18 Feb 2014 15:10:42 GMT+1
>> To: "Wang Xiaoqiang" <[email protected]>
>>
>> Hi Wang,
>>
>> You are correct in saying that the _DLL macro is wrongly used in
sharelib.h - it is a conceptual error, meaning as it does that code is
being DLL-linked to Microsoft's VS libraries.
>> The EPICS_DLL_NO macro is correct to say that code is being built
statically to EPICS user libraries.
>>
>> It has been corrected, for later releases.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>> -----Original Message-----
>> From: [email protected] 
>> [mailto:[email protected]] On Behalf Of Wang Xiaoqiang
>> Sent: 18 February 2014 12:13
>> To: epics
>> Subject: epics base with MinGW-w64
>>
>> Hi core developers,
>>
>> Sorry this is a long post and the question at the very end.
>>
>> I am using MinGW- w64 (http://mingw-w64.sourceforge.net/) on a
Windows 7 64bit PC to compile base 3.14.12.4.
>> It builds all OK by default. It stops with errors if configured to
build statically.
>>
>> make[1]: Entering directory
>>
`C:/epics/base-3.14.12.4-VC9/src/toolsComm/antelope/O.windows-x64-mingw'
>> ""
>> gcc -c             -D_MINGW     -O3   -Wall     -m64   -DEPICS_DLL_NO
>> -MMD -I. -I../O.Common -I. -I.. -I../../../../include/os/WIN32
>> -I../../../../include    ../main.c
>> g++ -o antelope.exe -static
>> -LC:/epics/base-3.14.12.4-VC9/lib/windows-x64-mingw     -m64     
>>  closure.o error.o lalr.o lr0.o main.o mkpar.o output.o reader.o
>> skeleton.o symtab.o verbose.o warshall.o   -lCom      -lws2_32
>> main.o:main.c:(.text.startup+0x2a6): undefined reference to
`__imp_epicsTempFile'
>> collect2.exe: error: ld returned 1 exit status
>> make[1]: *** [antelope.exe] Error 1
>> make[1]: Leaving directory
>> `C:/epics/base-3.14.12.4-VC9/src/toolsComm/antelope/O
>> .windows-x64-mingw'
>> make: *** [install.windows-x64-mingw] Error 2
>>
>> Looking at base-3.14.12.4-VC9/include/shareLib.h, it is apparently
somewhere '_DLL' has be defined.
>> And indeed it is that MinGW-w64 always has '_DLL' defined in 
>> '_mingw.h',
>> /* We have to define _DLL for gcc based mingw version. This define is
set
>>   by VC, when DLL-based runtime is used. So, gcc based runtime just
have
>>   DLL-base runtime, therefore this define has to be set.
>>   As our headers are possibly used by windows compiler having a
static
>>   C-runtime, we make this definition gnu compiler specific here.  */ 
>> #if !defined (_DLL) && defined (__GNUC__) #define _DLL #endif
>>
>> So far the fault is on the side of MinGW-w64. 
>>
>> But I have a question about the valid use of '_DLL' macro in
'shareLib.h'
>> According to MSDN, _DLL is defined when epics is built to DLL
libraries, otherwise not.
>> It is perfectly fine if both client program and epics base are built
statically or dynamically.
>> If one wants to mix them, there is the problem. 
>> I often need to compile my python extensions (DLLs by its essence) to
link to EPICS statically.
>> In such cases, _DLL is defined because the "client program" is
compiled to DLL not the "EPICS base libraries". 
>> This will cause confusion, I workaround it by undefine _DLL macro.
>>
>> So now it comes to my question: since macro EPICS_DLL_NO is the only
indication whether EPICS base is built statically or not, is it valid to
use it instead of _DLL in shareLib.h ......
>> #   else
>> #       if not defined(EPICS_DLL_NO) /* this indicates that we are
being
>> compiled to call DLLs */
>> #           define epicsShareExtern __declspec(dllimport) extern 
>> #           define epicsShareClass  __declspec(dllimport) 
>> #           define epicsShareFunc  __declspec(dllimport)
>> #       else
>> #           define epicsShareExtern extern
>> #           define epicsShareClass
>> #           define epicsShareFunc
>> #       endif
>> ......
>>
>> Best
>> Xiaoqiang
>>
> 
> 

--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock



Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System