Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Wed, 7 Feb 2018 09:49:46 -0800

On 02/07/2018 06:26 AM, [email protected] wrote:
> Hi Michael,
> 
> I've usually ended up fixing such things by a bit of trial and error/seen if before, but that is easier if you have a windows box to hand to quickly tell when you have guessed wrong!  What ultimately needs to happen is that all the external module includes happen in "import mode" and those of the module itself happen in "export mode". Including all such external headers explicitly before the  "include <epicsExport.h>" and module specific headers would achieve this, and commenting out includes in the module's header files would allow you to determine the needed files by brute force as you did.

> 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.

I've toyed with this idea as well.  Usually after an episode like this one.  The basic idea being to key on '#include ""' vs. '#include <>'
as a means of identifying "local" vs. external headers.  This isn't technically bullet proof, but it's the convention I use.
The basic logic being that no external headers can be included while epicsExportSharedSymbols is defined.

So far I haven't gotten anything which works very well.  The GCC pre-process mode doesn't include enough information
to judge this (I think), and writing/using a different pre-processor is a fair amount of work.

>  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.   

Well, if you want to depend on shareLib.h, then these are the rules.  I would personally rather have what
I've seen with other libraries supporting DLLs, which is that each library has it's own import/export macro.
This would get rid of the order dependency.

I would point to the generate_export_header() macro of CMake as an example
of how this can be accomplished at scale.

It's seems natural to me to wrap this up as part of header generated
by genVersionHeader.pl and fill two requirements at once.  (imo all
modules which install headers should publish ABI version as a macro)

> Regards,
> 
> Freddie  
> 
> -----Original Message-----
> From: Michael Davidsaver [mailto:[email protected]] 
> Sent: 06 February 2018 23:52
> To: Akeroyd, Freddie (STFC,RAL,ISIS)
> Cc: [email protected]; [email protected]
> Subject: Re: Build error for windows-x64-debug on VS2010
> 
> Freddie,
> 
> Do you by lucky chance have a recipe for finding where #include<>s are needed before a link error is observed?  I've just had one round of the brute force method of commenting out all #include<> in header files, then adding #include<>s to the source files until things compile again.
> 
> There must be a better way...
> 
> Michael
> 
> 
> On 02/06/2018 03:43 PM, [email protected] wrote:
>> Hi Mark,
>>
>> Do the enclosed changes fix it?
>>
>> Regards,
>>
>> Freddie
>>
>> -----Original Message-----
>> From: [email protected] 
>> [mailto:[email protected]] On Behalf Of Mark Rivers
>> Sent: 06 February 2018 22:47
>> To: 'Michael Davidsaver'
>> Cc: [email protected]
>> Subject: RE: Build error for windows-x64-debug on VS2010
>>
>> Hi Michael,
>>
>> That fixed that error.  I then got the same error with channel.cpp, so I did the same fix in that file.
>>
>> That then leads to this error, which I don't know how to fix:
>>
>> make[1]: Entering directory 'H:/epics-devel/base-7.0.1/modules/pva2pva/pdbApp'
>> make -C O.windows-x64-debug -f ../Makefile TOP=../.. \
>>     T_A=windows-x64-debug install
>> make[2]: Entering directory 'H:/epics-devel/base-7.0.1/modules/pva2pva/pdbApp/O.windows-x64-debug'
>> link -nologo -subsystem:windows -dll -debug -incremental:no -fixed:no -MACHINE:X64      -out:qsrv.dll -implib:qsrv.lib        pvif.obj qsrv.obj pdb.obj pdbsingle.obj demo.obj image
>> demo.obj pdbgroup.obj configparse.obj      H:/epics-devel/base-7.0.1/lib/windows-x64-debug/pvAccess.lib  H:/epics-devel/base-7.0.1/lib/windows-x64-debug/pvData.lib  H:/epics-devel/
>> base-7.0.1/lib/windows-x64-debug/dbRecStd.lib  
>> H:/epics-devel/base-7.0.1/lib/windows-x64-debug/dbCore.lib  
>> H:/epics-devel/base-7.0.1/lib/windows-x64-debug/ca.lib  
>> H:/epics-devel/ba se-7.0.1/lib/windows-x64-debug/Com.lib
>> 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
>> H:/epics-devel/base-7.0.1/configure/RULES_BUILD:288: recipe for target 
>> 'qsrv.dll' failed
>> make[2]: *** [qsrv.dll] Error 1169
>> make[2]: Leaving directory 'H:/epics-devel/base-7.0.1/modules/pva2pva/pdbApp/O.windows-x64-debug'
>> H:/epics-devel/base-7.0.1/configure/RULES_ARCHS:58: recipe for target 
>> 'install.windows-x64-debug' failed
>> make[1]: *** [install.windows-x64-debug] Error 2
>> make[1]: Leaving directory 'H:/epics-devel/base-7.0.1/modules/pva2pva/pdbApp'
>> H:/epics-devel/base-7.0.1/configure/RULES_DIRS:84: recipe for target 
>> 'pdbApp.install' failed
>> make: *** [pdbApp.install] Error 2
>>
>>> -----Original Message-----
>>> From: Michael Davidsaver [mailto:[email protected]]
>>> Sent: Tuesday, February 06, 2018 4:28 PM
>>> To: Mark Rivers <[email protected]>
>>> Cc: [email protected]
>>> Subject: Re: Build error for windows-x64-debug on VS2010
>>>
>>> On 02/06/2018 01:25 PM, Mark Rivers wrote:
>>>> I am getting an error building pva2pva for the windows-x64-debug 
>>>> architecture on
>>> VS2010.  I don't think this is an error I have previously reported.  
>>> I don't know how to fix it.
>>> ...
>>>>
>>>> link -nologo  -debug -incremental:no -fixed:no -MACHINE:X64
>>>> -
>>> out:p2p.exe       gwmain.obj server.obj chancache.obj moncache.obj 
>>> channel.obj     H:/epics-
>>> devel/base-7.0
>>>>
>>>> .1/lib/windows-x64-debug/pvAccessIOC.lib
>>>> H:/epics-devel/base-7.0.1/lib/windows-x64-
>>> debug/pvAccess.lib
>>> H:/epics-devel/base-7.0.1/lib/windows-x64-debug/pvData.lib  H:/epics- 
>>> devel/b
>>>>
>>>> ase-7.0.1/lib/windows-x64-debug/Com.lib
>>>>
>>>> Com.lib(Com.dll) : error LNK2005: "public: __cdecl
>>> epicsTimerNotify::epicsTimerNotify(void)" 
>>> (??0epicsTimerNotify@@QEAA@XZ) already defined in server.obj
>>>>
>>>>    Creating library p2p.lib and object p2p.exp
>>>>
>>>> p2p.exe : fatal error LNK1169: one or more multiply defined symbols 
>>>> found
>>>
>>> Gosh Mark, you sure find some good issues.
>>>
>>> Let's assume this is an dllimport vs. export bug.  Can you add the 
>>> following to p2pApp/server.cpp above the epicsExportSharedSymbols and 
>>> see if the situation changes at all?
>>>
>>>> #include <epicsTimer.h> // add this line #define 
>>>> epicsExportSharedSymbols
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System