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 Wang Xiaoqiang
- RE: Fwd: epics base with MinGW-w64 Wang Xiaoqiang
- References:
- Fwd: epics base with MinGW-w64 Xiaoqiang Wang
- Navigate by Date:
- Prev:
Re: Running Linux commands inside 'st.cmd' Andrew Johnson
- 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
<2014>
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Fwd: epics base with MinGW-w64 Xiaoqiang Wang
- Next:
RE: Fwd: epics base with MinGW-w64 Wang Xiaoqiang
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
<2014>
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|