Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 25 Feb 2014 16:06:47 -0600

Hi Xiaoqiang,

I have converted your changes plus a few others in blockingSockTest.cpp
into a patch which can be found on the 3.14 Known Problems page, and
have also committed these changes to the 3.14 branch of Base.

Thank-you very much,

- Andrew

On 02/21/2014 04:06 AM, Wang Xiaoqiang wrote:
> 
> Hi Andrew, 
> 
> I forgot the second failure it incurs: failed when building as
> shared-libraries.
> This is because src\catools\Makefile asks to build "tool_lib.c" as a
> private static library.
> And in 3.15.0.1 src\ca\client\tools\Makefile, this has been fixed by
> linking directly the object file.
> 
> I replaced the Makefile with the one in 3.15.0.1 and it built with
> success.
> 
> 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
> 

-- 
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