CORBA：Link error2005 with a custom idl library

解决办法：一般情况下，这是由于模版的机制造成的，这说明CORBA已经为我们实现了这个模版，我们直接使用即可。

Hi,

Thanks for using the PRF form.

I think this is an issue that is VC71 specific. I think it can be related to
the same problem as the changelog entry below. The problem is that this IDL
generated code and this is a hard one to solve in a generic way. The best is
to get MS fix their bug, until that moment, if you really need to use the
setup as you described, try to use the same trick as done below by hand.

Regards,

Johnny Willemsen
Remedy IT
Leeghwaterstraat 25
2811 DT Reeuwijk
The Netherlands
www.theaceorb.nl / www.remedy.nl


Thu Apr 15 14:27:12 2004 Jeff Parsons <j.parsons@...>

* tao/OctetSeqC.h:

Reluctantly added a handcraft to this generated file, but it
wouldn't work anywhere else. Visual Studio .NET has a bug
(see
http://support.microsoft.com/default.aspx?scid=kb;en-us;309801)
where a template base class is not imported correctly, leading
to 'multiply defined' link errors if an application has a
child of the same base class. The TAO POA library uses a
sequence of CORBA::OctetSeq, resulting in the above link error
if an application server uses the same type. Since the conflict
is with *C.obj, the fix must go into a file that will be included
in that translation unit, to force the correct import. We force
the import with

#if defined ACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION_EXPORT
template class TAO_Export
TAO_Unbounded_Sequence<CORBA::OctetSeq>;
#endif /* ACE_HAS_EXPLICIT_TEMPLATE_INSTANTIATION_EXPORT */

and the TAO export macro will be read by the application as
__declspec(dllimport). Placement of the instantiation was tricky,
since it had to be a place where

- TAO_Unbounded_Sequence is known
- CORBA::OctetSeq is known
- the instantiation will be seen when building *C.obj
- it will not conflict with the implicit PortableServer export

Thanks to Bala <bala@...> for his help with this
bug, and to Scott Gammill <zumo@...> for both reporting
the bug and for pointing us to the Microsoft Knowledge Base
article
that finally explained it.

* tests/IDL_Test/sequence.idl:

Added IDL to test for the above bug.

"Stelios G. Sfakianakis" <ssfak@...> wrote in message
news:<41061B28.4010207@...>...
> TAO VERSION: 1.4.1
> ACE VERSION: 5.4.1
>
> HOST MACHINE and OPERATING SYSTEM: Windows 2000 / Winsock 2
> COMPILER NAME AND VERSION (AND PATCHLEVEL): MS Visual C++ .NET
> 69586-335-0000007-18643 (Visual Studio Version 7.1.3088)
>
> DOES THE PROBLEM AFFECT:
> COMPILATION? no
> What do your $ACE_ROOT/ace/config.h contain?
> #define ACE_HAS_STANDARD_CPP_LIBRARY 1
> #define TAO_HAS_RT_CORBA 1
> #define TAO_HAS_SMART_PROXIES 1
> #define TAO_HAS_INTERCEPTORS 1
> #define TAO_HAS_CORBA_MESSAGING 1
> #include "ace/config-win32.h"
>
> LINKING? yes
>
> SYNOPSIS:
> During the linking of a static library that contains the stubs and
> skeletons of my idls with the server files I get this link error:
>
> TAOd.lib(TAOd.dll) : error LNK2005: "public: class
> TAO_Pseudo_Object_Manager<class CORBA::TypeCode> __thiscall
> TAO_Unbounded_Pseudo_Sequence<class
> CORBA::TypeCode>::operator[](unsigned int)const "
>
(??A?$TAO_Unbounded_Pseudo_Sequence@VTypeCode@CORBA@@@@QBE?AV?$TAO_Pseudo_Ob
ject_Manager@VTypeCode@CORBA@@@@I@Z)
> already defined in libIDL_d.lib(CosPropertyServiceC.obj)
>
>
> DESCRIPTION:
>
> I have 5-6 idl files that are related and I have a VC++ project that
> builds a static library of their stubs and skeletons. This library is to
> be linked with client and server code to produce the respective
> executables. All the idls are compiled with the following command (in
> the "custom build step"):
>
> $(ACE_ROOT)\bin\tao_idl -Sc -Wb,pre_include=ace/pre.h
> -Wb,post_include=ace/post.h -I $(TAO_ROOT) "$(InputName)".idl
>
> One of the idl files is the CosPropertyService.idl that uses definitions
> that come from the orb.idl, i.e.
>
> //File: CosPropertyService.idl
> //version: 98-10-28
> //The only module of the Property Service
>
> #ifndef _COS_PROPERTY_SERVICE_IDL_
> #define _COS_PROPERTY_SERVICE_IDL_
> #pragma prefix "omg.org"
>
> #include <orb.idl>
>
> module CosPropertyService
> {
> // ...
> typedef sequence<CORBA::TypeCode> PropertyTypes;
> // ...
> };
>
> The compilation of the static library (libIDL_d.lib) goes all right but
> then during the linking phase of the server executable I get a link error:
>
> TAOd.lib(TAOd.dll) : error LNK2005: "public: class
> TAO_Pseudo_Object_Manager<class CORBA::TypeCode> __thiscall
> TAO_Unbounded_Pseudo_Sequence<class
> CORBA::TypeCode>::operator[](unsigned int)const "
>
(??A?$TAO_Unbounded_Pseudo_Sequence@VTypeCode@CORBA@@@@QBE?AV?$TAO_Pseudo_Ob
ject_Manager@VTypeCode@CORBA@@@@I@Z)
> already defined in libIDL_d.lib(CosPropertyServiceC.obj)
>
> The linker subsequently fails with an "one or more multiply defined
> symbols found" error.
>
> REPEAT BY:
> I tried to build a minimal test case that excibits the same problem but
> I did't manage it :-{
>
> SAMPLE FIX/WORKAROUND:
>
> If I remove the CosPropertyService.idl from the idls that build the
> static library and then use the TAO_CosPropertyd.lib, i.e. the code that
> builds as (shared) library from the TAO distribution, linked with the
> server then there is no problem! Maybe if I also build a shared library
> I would not have this problem, but I haven't tested that.
>
> Any comments are welcome!
> Thanks for your time!
> --
> Stelios G. Sfakianakis | Center of Medical Informatics
> Voice: +30-2810-391650 | Institute of Computer Science
> PGP Key ID: 0x5F30AAC2 | FORTH, http://www.forth.gr
>