[omniORB] VC7.1, Templates, and DLLs

[Okeefe, Michael K]

"We didn't have this problem with VC6 - is this due to changes
(enhancements?) in the linker?"

There were issues with templates handled differently in the VC7
compiler, it caused problems with Qt but these seem to have been fixed
(Qt? VC?) as you can compile with later versions of VC. Even with VC6
you needed the latest, patched version to compile Qt.

Here's the similar issue, except with the '__declspec(dllexport)' from
the Qt archive:

http://lists.trolltech.com/qt-interest/2002-03/thread00119-0.html
<http://lists.trolltech.com/qt-interest/2002-03/thread00119-0.html> 

-----Original Message-----
From: omniorb-list-bounces at omniorb-support.com
[mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of Mark
Johnson
Sent: Wednesday, May 25, 2005 4:04 PM
To: omniORB
Subject: [omniORB] VC7.1, Templates, and DLLs


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_Structur
edPushSupplier_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
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/20050526/5c6fee04/attachment.htm