[omniORB] Windows NT and dllimport/dllexport

[Sai-Lai Lo]

Ted,

Yes, I have thought of the problem you have with building stubs into DLLs.
The USE_core_stub_in_nt_dll_NOT_DEFINED_X are there exactly for this
purpose. However, the usage is not quite as you have described. Let me
explain.

The best example of how the current scheme is supposed to work is the
building of the COS (CORBA Object Services) stub library that comes with
omniORB since 3.0.2.  The idea is that we built the COS stubs into DLLs but
may be a developer would want to write a new IDL that derives from the COS
IDLs. She would like to make the stubs of the new IDL into DLLs and reuse
the COS DLLs as well. I think this is the situation you are referring to.

The current scheme works like this:

1. Inside each of the COS idl, e.g. <top>/idl/COS/CosEventComm.idl, there
   is these extra pragmas at the top:

// omniORB specific pragmas to insert extra includes into the stub header.
#pragma hh #ifndef __COS_SYSDEP_H_EXTERNAL_GUARD__
#pragma hh #define __COS_SYSDEP_H_EXTERNAL_GUARD__
#pragma hh #include "COS_sysdep.h"
#pragma hh #endif


   The pragmas are dumped verbatim into the stub header.

2. The header file <top>/include/COS/COS_sysdep.h is a hand written file
   containing the following:

#if !defined(_COS_LIBRARY)

#define USE_core_stub_in_nt_dll
#define USE_dyn_stub_in_nt_dll

#endif

3. When we built the COS stubs into DLL, we use the _COS_LIBRARY 
   pre-processor define. In other words, USE_core_stub_in_nt_dll etc would
   not be defined. The DLL would built normally.

4. Now if you look into any of the stub header files, e.g.
   <top>/include/COS/CosEventComm.hh, you will see that

USE_core_stub_in_nt_dll_NOT_DEFINED_CosEventComm

and

USE_dyn_stub_in_nt_dll_NOT_DEFINED_CosEventComm

   are used to record whether USE_core_stub_in_nt_dll and
   USE_dyn_stub_in_nt_dll are defined before this include file is hit.

   The macros are tested at the end of the header file to restore the
   state of the USE* macro at the beginning of the file.

   The tricky bit is that #include "COS_sysdep.h" turns on both
   USE_{core,dyn}_stub_in_nt_dll and so the dllimport attribute will be
   correctly set for all the symbols in the COS dlls. But then at the end
   of the COS header files, the macros are restored to the state outside
   the library. It may take a bit of thinking but you can see doing it this
   way means that any idl stubs can be build into DLLs that use the COS
   DLLs.


Sorry if what I've written is confusing. You should really look at how the
COS library is built to understand the black magic. The same mechanism can
be used for any DLLs. Admittedly, this is an ugly hack that any sane person
would vomit on seeing it, which is why I've been keeping quiet about it for
so long :-)

Regards,

Sai-Lai


-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND