Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Thu, 28 May 2015 22:34:04 +0000

Hi Peter,

I just fixed some problems in motor/motorApp/NewportSrc.  The files changed are:

SMC100Driver.cpp
HXPDriver.cpp
hxp_drivers.h
hxp_drivers.cpp

With these fixes there are no errors or warnings that are related to symbols or DLLs when building the entire motor module on win32-x86-debug or windows-x64-debug.  These fixes are committed to SVN.

Regarding asyn (and your comments would apply to many other modules as well), I have discussed this issue with Andrew Johnson, and there are two methods that can be used to set the import/export symbols correctly.

1) The first approach is the one you have proposed, for example in paramVal.h:

#ifdef epicsExportSharedSymbols
#define paramVal_epicsExportSharedSymbols
#undef epicsExportSharedSymbols
#endif

#include "stdio.h"
#include "epicsTypes.h"

#ifdef paramVal_epicsExportSharedSymbols
#undef paramVal_epicsExportSharedSymbols
#define epicsExportSharedSymbols
#endif

2) The second solution is simply to include those header files from external modules (stdio.h and epicsTypes.h in this case) in any C/C++ files in this library that is including paramVal.h before defining epicsExportSharedSymbols and before paramVal.h is included.   That is the approach I have taken in asyn, and in all of the other modules I am responsible for.

Method 1) has the advantage that it is a little easier to maintain, because if a new header file from an external module is needed it only needs to be added to this header file, not to the C/C++ files.  However, one only needs to worry about this for C/C++ source files that are in the same library that is exporting the symbols in that header file, paramVal.h in this case.  It is not an issue in source files that are importing these symbols.  The disadvantage of method 1) is that it is wordy and rather ugly in my opinion.

Method 2) is a little more work to maintain, but it leads to much more readable code in my opinion.

I believe both methods are functionally equivalent, and I have seen no errors or warnings when using method 2) to build any of the synApps modules, for example.

Mark

________________________________________
From: Heesterman, Peter J [[email protected]]
Sent: Wednesday, May 27, 2015 9:02 AM
To: Mark Rivers; EPICS Tech Talk
Subject: RE: Motor R6-9 build issues on Windows

Hi Mark,

Actually, the issues that need to be addressed first, are in Asyn.

Where the header files of a module (such as Asyn, in this case) import from another module (such as Com, in this case), but also in turn export to other modules (such as Motor, in this case), it is pretty essential to manipulate the epicsExportSharedSymbol define so that the importing headers each import, and the exporting headers each export.

See my attached header files from the Asyn module, which I believe are doing so correctly.

You'll see that epicsExportSharedSymbol is turned off before #including headers from the EPICS base.
Then the value of the define is cached, and restored, before being applied the definitions of (this) header.

This is quite well expressed in the comments of shareLib.h.

There are also some build issues in the Motor project that need to be looked at.

Cheers,

Peter.

-----Original Message-----
From: Mark Rivers [mailto:[email protected]]
Sent: 27 May 2015 12:05
To: Heesterman, Peter J; EPICS Tech Talk
Subject: RE: Motor R6-9 build issues on Windows

Hi Peter,

I fixed the problem with phytronAxisMotor back in March and committed to SVN.

I fixed many problems with NewportSrc on May 6 to get it to build on Cygwin, which is also much more sensitive to the correct name decorations than the Visual Studio release compiler.  I committed those fixes to SVN as well.  I have not tried building the win32-x86-debug arch, but my fixes for Cygwin may well have fixed those problems.

Can you try checking out the SVN trunk from /https://subversion.xray.aps.anl.gov/synApps/motor/trunk/  and see if there are still problems?

Mark

________________________________
From: [email protected] [[email protected]] on behalf of Heesterman, Peter J [[email protected]]
Sent: Wednesday, May 27, 2015 5:52 AM
To: EPICS Tech Talk
Subject: Motor R6-9 build issues on Windows

Hi,

I would like to highlight some build issues, on Windows, with the R6-9 release of the Motor project.

I am building with the following library versions:

a.       Base 3.15.1

b.      Seq 2.1.15

c.       Ipac 2-10

d.      Asyn 4-26

Trivial issue: phytronAxisMotor.cpp #includes unistd.h – which is not a header file under Windows.
Fix: The file isn’t required, as far as I can see, and can be removed.

Non-trivial issue: A release-x86 build completes normally, but  a debug-x86 build fails with numerous DLL linker warnings and errors (see attached).
I’m not sure I understand why a debug build is so much more sensitive to these problems, than is a release build.

I would be able to address many of the build issues.

Thanks,

Peter.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System