[omniORB] VC7.1, Templates, and DLLs

[Mark Johnson]

Hi,

I've been in the process of upgrading our development environment from 
VC6 (Visual Studio 6) to VC7.1 (Visual Studio .NET 2003) and ran across 
some problems.  This was caused by a combination of several ways we use 
omniORB and I'm not sure if anyone else has run into this.  Here's the 
setup:

- We have implemented Cos Notification services and use the 
flattened-tie classes generated by the idl compiler (omniidl -bcxx 
-Wba,tf  etc.).  The idl compiler generates template definitions for 
these such as the following (pertinent part only, from the header file 
for CosNotifyCom.idl):

<snip>

template <class _dyn_attr _omniT>
class _dyn_attr POA_CosNotifyComm_StructuredPushSupplier_tie : public 
virtual POA_CosNotifyComm::StructuredPushSupplier
{

<snip>

- We link all our stubs into one dll, thus use the USE_stub_in_nt_dll 
define for all programs.  The stubs for CosNotification, CosNotifyComm, 
CosNotifyChannelAdmin, etc., are all included in this stub dll.

What happens when we compile an application that makes use of one of 
these templates, and the fact that we're defining USE_stub_in_nt_dll,  
the method signature results in something like:

__declspec(dllimport) public: __thiscall 
POA_CosNotifyComm_StructuredPushSupplier_tie::POA_CosNotifyComm_StructuredPushSupplier_tie(class 
Service_i *,bool)

This compiles fine, but throws a LNK2019: unresolved external symbol 
during the link, due to the "__declspec(dllimport)" I believe, since the 
template expansion is not part of the stubs dll, but expanded locally in 
the object file generated by the compiler, and the storage class 
attribute is dllimport.

The fix was to hack the header file and remove the _dyn_attr from the 
template definitions.  This changed the storage class attributes on the 
generated templates so they could be linked from the local object file.  
We didn't have this problem with VC6 - is this due to changes 
(enhancements?) in the linker?

I'm wondering if the modifier "_dyn_attr" should be removed from 
template definitions generated by the idl compiler?

I'm also trying to fix a problem with duplicate definitions:

cos.lib(any.obj) : error LNK2005: "public: __thiscall 
_CORBA_Unbounded_Sequence::~_CORBA_Unbounded_Sequence(void)" 
(??1?$_CORBA_Unbounded_Sequence at VAny@CORBA@@@@QAE at XZ) already defined in 
omniDynamic406_rtd.lib(omniDynamic406_rtd.dll)

We have some utilities that work on CORBA::Any types and it seems the 
template for _CORBA_Unbounded_Sequence< CORBA::Any> was generated in our 
code as well as in omniDynamic (???).

Any suggestions or comments appreciated!

Mark

-- 
Mark A. Johnson
NetQoS, Inc.
60 E. Marie Ave
Suite 204
West St. Paul, MN 55118
Office: (01) 651.552.2111

mark at redpt.com <mailto:mark at redpt.com>
http://www.redpt.com <http://www.redpt.com/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20050525/4d4c8bad/attachment.htm