RE: Build error for windows-x64-debug on VS2010

[<freddie.akeroyd@stfc.ac.uk>]

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

Regards,

Freddie  

-----Original Message-----
From: Michael Davidsaver [mailto:mdavidsaver@gmail.com] 
Sent: 06 February 2018 23:52
To: Akeroyd, Freddie (STFC,RAL,ISIS)
Cc: rivers@cars.uchicago.edu; core-talk@aps.anl.gov
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, freddie.akeroyd@stfc.ac.uk wrote:
> Hi Mark,
> 
> Do the enclosed changes fix it?
> 
> Regards,
> 
> Freddie
> 
> -----Original Message-----
> From: core-talk-bounces@aps.anl.gov 
> [mailto:core-talk-bounces@aps.anl.gov] On Behalf Of Mark Rivers
> Sent: 06 February 2018 22:47
> To: 'Michael Davidsaver'
> Cc: core-talk@aps.anl.gov
> 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:mdavidsaver@gmail.com]
>> Sent: Tuesday, February 06, 2018 4:28 PM
>> To: Mark Rivers <rivers@cars.uchicago.edu>
>> Cc: core-talk@aps.anl.gov
>> 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