Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 7 Feb 2018 11:56:58 -0600

Hi Freddie,

On 02/07/2018 08:26 AM, [email protected] wrote:
> 
> To remove the "brute force" it might be possible to use a
> "makedepend" type tool to generate the list of external
> headers used by a particular source file and then make sure
> that these are mentioned before the <epicsExport.h> etc.

The list of headers is already available in the .d file that the build
system generates inside the O.<arch> directory for each .c and .cpp
file. Writing a tool that checks the includes compared to where
epicsExportSharedSymbols gets defined sounds like an interesting idea,
maybe a project for a summer student if anyone has one...

> The most bulletproof approach, however, would be to protect
> headers as per the comments in the EPICS <shareLib.h>  file
> so that import/export are swapped automatically.
I disagree that the #ifdef epicsExportSharedSymbols thing discussed in
shareLib.h is bulletproof. In my experience that construct actually
makes it much harder to track down the location of any mistakes.

It is usually relatively easy to find a source file which has an include
in the wrong place (above/below the #define epicsExportSharedSymbols or
#include <epicsExport.h> statement) because the error is usually
reported in the build or link of that file and gives the name of a
symbol which is in or related to the include file that needs to be moved.

With the other approach the error is actually in a header file, and no
indication is given at compile-time which header needs to be fixed. This
approach also clutters up the header files with this weird conditional
construct, and it doesn't take away the need to get the includes right
in the source file (look at dbEvent.h and src/ioc/db/dbEvent.c for an
example).

Here's the error message that Mark reported:

> pvAccess.lib(pvAccess.dll) : error LNK2005: "public: virtual __cdecl 
> epics::pvAccess::ChannelFind::~ChannelFind(void)" 
> (??1ChannelFind@pvAccess@epics@@UEAA@XZ) already defined in qsrv.obj
> pvAccess.lib(pvAccess.dll) : error LNK2005: "public: __cdecl epics::pvAccess::ChannelFind::ChannelFind(void)" (??0ChannelFind@pvAccess@epics@@QEAA@XZ) already defined in qsrv.obj
>    Creating library qsrv.lib and object qsrv.exp qsrv.dll : fatal 
> error LNK1169: one or more multiply defined symbols found

This tells me that whatever header file declares the routine
   epics::pvAccess::ChannelFind::~ChannelFind(void)
is probably listed the wrong side of the epicsExportSharedSymbols
definition inside the source file that created qsrv.obj. Sure enough,
Mark reported the error was fixed by your change to qsrv.cpp (which
moves the #include <epicsExport.h> that also defines the macro
epicsExportSharedSymbols; I would like to change that, but it would
require so many updates to out-of-tree code that I think it would be too
painful to do).

The only difficulty is generally remembering that this kind of error is
caused by the include order in the source file. What I don't understand
is why the compiler wasn't complaining about any other symbols defined
in headers that were also the wrong side of #include <epicsExport.h>,
but I've given up trying to understand Microsoft's compiler.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System