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
- References:
- Fwd: epics base with MinGW-w64 Xiaoqiang Wang
- Re: Fwd: epics base with MinGW-w64 Andrew Johnson
- RE: Fwd: epics base with MinGW-w64 Wang Xiaoqiang
- Navigate by Date:
- Prev:
Re: Monitoring whether an IP device is connected or not Dohn Arms
- Next:
Fw: Re: Error in building epics base-3.15.0.1 on windows XP (32 bit) using mingw Anindya Roy
- 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:
RE: Fwd: epics base with MinGW-w64 Wang Xiaoqiang
- Next:
Asyn commands not found in Motor record WithAsyn example? Gomella, Andrew (NIH/NHLBI) [F]
- 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
|