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
- Navigate by Date:
- Prev:
Re: Bayer vs RGB1 performance for Prosilica cameras Bruce Hill
- Next:
RE: Bayer vs RGB1 performance for Prosilica cameras Mark Rivers
- 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: Bayer vs RGB1 performance for Prosilica cameras Bruce Hill
- Next:
Fwd: epics base with MinGW-w64 Xiaoqiang Wang
- 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
|