RE: Sequencer build errors on Windows

["Mark Rivers" <rivers@cars.uchicago.edu>]

Title: Re: Sequencer build errors on Windows

Hi Ben,

 

I just tested the behavior of my asynPortDriver class when building dynamically on win32-x86.

 

If I declare the class as follows it works fine.  My testAsynPortDriverApp links and runs fine.

 

class epicsShareFunc asynPortDriver {

public:

 

 

If I delete the epicsShareFunc in the definition of the class then I get the following link errors when building testAsynPortDriverApp:

 

cl /nologo /EHsc /GR -c               /nologo /D__STDC__=0 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE   /Ox/GL   /W3 /w44355     /D_WIN32_WINNT=0x0503   /MD  /TP   -I. -I..\\O.Common -I. -I.. -I..\\..\\..\\include\\os\\WIN32 -I..\\..\\..\\include    -IJ:\\epics\\devel\\ipac-2-11\\include  -IJ:\\epics\\devel\\seq-2-1-3\\include   -IH:\\epics\\base-3.14.12.2\\include\\os\\WIN32 -IH:\\epics\\base-3.14.12.2\\include       ..\\testAsynPortDriver.cpp

testAsynPortDriver.cpp

link /nologo /subsystem:windows /dll /LTCG /incremental:no /opt:ref /release       /implib:testAsynPortDriverSupport.lib /out:testAsynPortDriverSupport.dll         testAsynPortDriver.obj      ..\\..\\..\\lib\\win32-x86-dynamic\\asyn.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\recIoc.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\softDevIoc.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\miscIoc.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\rsrvIoc.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\dbtoolsIoc.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\asIoc.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\dbIoc.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\registryIoc.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\dbStaticIoc.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\ca.lib  H:\\epics\\base-3.14.12.2\\lib\\win32-x86-dynamic\\Com.lib

   Creating library testAsynPortDriverSupport.lib and object testAsynPortDriverSupport.exp

testAsynPortDriver.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall asynPortDriver::reportParams(struct _iobuf *,int)" (?reportParams@asynPortDriver@@UAEXPAU_iobuf@@H@Z)

testAsynPortDriver.obj : error LNK2001: unresolved external symbol "public: virtual enum asynStatus __thiscall asynPortDriver::callParamCallbacks(void)" (?callParamCallbacks@asynPortDriver@@UAE?AW4asynStatus@@XZ)

testAsynPortDriver.obj : error LNK2001: unresolved external symbol "public: virtual enum asynStatus __thiscall asynPortDriver::callParamCallbacks(int)" (?callParamCallbacks@asynPortDriver@@UAE?AW4asynStatus@@H@Z)

testAsynPortDriver.obj : error LNK2001: unresolved external symbol "public: virtual enum asynStatus __thiscall asynPortDriver::callParamCallbacks(int,int)" (?callParamCallbacks@asynPortDriver@@UAE?AW4asynStatus@@HH@Z)

…

 

So it appears to be both necessary and sufficient to put the epicsShareFunc in the definition of the class itself.

 

Mark

 

 

________________________________________

From: Mark Rivers

Sent: Friday, December 16, 2011 7:19 AM

To: Benjamin Franksen; Josh Stein

Cc: benjamin.franksen@bessy.de; tech-talk@aps.anl.gov

Subject: RE: Sequencer build errors on Windows

 

Hi Ben,

 

I normally build statically on win32-x86, so I don't have a lot of experience with ensuring that the functions are visible in DLLs.  However, I know that I did make it work with the asynPortDriver class in asyn, and this is what I did:

 

/** Base class for asyn port drivers; handles most of the bookkeeping for writing an asyn port driver

  * with standard asyn interfaces and a parameter library. */

class epicsShareFunc asynPortDriver {

public:

    asynPortDriver(const char *portName, int maxAddr, int paramTableSize, int interfaceMask, int interruptMask,

                   int asynFlags, int autoConnect, int priority, int stackSize);

    virtual ~asynPortDriver();

    virtual asynStatus lock();

    virtual asynStatus unlock();

    virtual asynStatus getAddress(asynUser *pasynUser, int *address);

    virtual asynStatus readInt32(asynUser *pasynUser, epicsInt32 *value);

    virtual asynStatus writeInt32(asynUser *pasynUser, epicsInt32 value);

    virtual asynStatus readUInt32Digital(asynUser *pasynUser, epicsUInt32 *value, epicsUInt32 mask);

    virtual asynStatus writeUInt32Digital(asynUser *pasynUser, epicsUInt32 value, epicsUInt32 mask);

 ...

 

So it was sufficient to declare the class with epicsShareFunc, not the individual methods.  I am quite sure that my test application that uses this class linked fine when building dynamically.

 

Mark

 

 

________________________________________

From: tech-talk-bounces@aps.anl.gov on behalf of Benjamin Franksen

Sent: Fri 12/16/2011 6:04 AM

To: Josh Stein

Cc: benjamin.franksen@bessy.de; tech-talk@aps.anl.gov

Subject: Re: Sequencer build errors on Windows

On Wednesday, December 07, 2011, Josh Stein wrote:

> Hello Benjamin and community,

> 

>    I am attempting to build version 2.1.3 of the sequencer on a windows

> machine. I have the MinGW tools installed along with a windows version

> of re2c. I have also already successfully built EPICS base, the example

> app and an older version of the sequencer (2.0.14) in the past.

> 

> When executing the build from the 2.1.3 top level directory, the

> following warnings and errors are shown and the make is stopped:

> 

> 

> 

> ../../../include/pv.h:75:37: warning: inline function 'pvSystem*

> pvSystem::getSystem()' declared as  dllimport: attribute ignored

> [-Wattributes]

> ../../../include/pv.h:77:35: error: function 'pvStat pvSystem::attach()'

> definition is marked dllimport

> ../../../include/pv.h:78:35: error: function 'pvStat pvSystem::flush()'

> definition is marked dllimport

 

I would like to pose this question to the community, especially the C++

experts.

 

These are the relevant lines:

 

class pvSystem {

 

public:

    epicsShareFunc pvSystem( int debug = 0 );

    epicsShareFunc virtual ~pvSystem();

 

    epicsShareFunc inline pvSystem *getSystem() { return this; }

 

    epicsShareFunc virtual pvStat attach() { return pvStatOK; }

    epicsShareFunc virtual pvStat flush() { return pvStatOK; }

...

}

 

The code in the src/pv subsystem in the sequencer uses 'epicsShareFunc' for

C++ class methods in many places (also in the method implementations). While

it seems it has worked so far, I wonder if epicsShareFunc' is necessary here

or even intended. I looked at some EPICS base header and cpp files and found

'epicsShareFunc' is not used for C++ class methods.

 

So, can I just remove 'epicsShareFunc' qualifiers on class methods?

 

At least on my win32-x86 VM this worked fine (build & tests).

 

Cheers

Ben

 

________________________________

 

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

 

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

 

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph

Geschäftsführer: Prof. Dr. Anke Rita Kaysser-Pyzalla, Dr. Ulrich Breuer

 

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

 

Postadresse:

Hahn-Meitner-Platz 1

D-14109 Berlin

 

http://www.helmholtz-berlin.de