EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Fwd: epics base with MinGW-w64
From: "Wang Xiaoqiang" <[email protected]>
To: "Andrew Johnson" <[email protected]>
Cc: epics <[email protected]>
Date: Fri, 21 Feb 2014 11:06:50 +0100
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


Replies:
Re: Fwd: epics base with MinGW-w64 Andrew Johnson
References:
Fwd: epics base with MinGW-w64 Xiaoqiang Wang
Re: Fwd: epics base with MinGW-w64 Andrew Johnson

Navigate by Date:
Prev: RE: Fwd: epics base with MinGW-w64 Wang Xiaoqiang
Next: RE: Epics/Raspberry Pi data acquisition Emmanuel Mayssat
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Fwd: epics base with MinGW-w64 Wang Xiaoqiang
Next: Re: Fwd: epics base with MinGW-w64 Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·