Experimental Physics and
Industrial Control System

"Wang Xiaoqiang" <[email protected]> · Tue, 18 Feb 2014 13:12:35 +0100

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System