[omniORB] packaging stubs in a dll

[Hayes, Ted (London)]

hi omniORB developers

I had a discussion about this (or at least a very similar) problem with
Sai-Lai a while back, and he explained the (not 100% documented) macro
scheme in the omniORB headers intended to get around the Microsoft problem.
This relies on an omniidl specific pragma.  If I am building a DLL server Y
that implements an interface YYY,  based on an interface XXX implemented in
another DLL server X, the scheme involves putting something like

#pragma hh #ifndef XXXIDL_EXTERNAL_GUARD
#pragma hh #define XXXIDL_EXTERNAL_GUARD
#pragma hh #ifndef XXXIDL_DLLPROXY
#pragma hh #define USE_core_stub_in_nt_dll
#pragma hh #define USE_dyn_stub_in_nt_dll
#pragma hh #endif
#pragma hh #endif

into XXX.idl (and similar stuff in YYY.idl, continuing down the chain of
client-server DLL invocations).

This works but I didn't like the idea of putting proprietary stuff in my
IDL.  For example, when I try to build a client by running the same IDL
through a Java IDL compiler, the pragmas generate warnings (a more
unfriendly jidl could refuse to compile altogether I guess).  In the end,
though, I adopted a different approach by using the macros in a different
way (0% documented of course) that doesn't need anything changing in the IDL
- my compiler flag setup for building YYY includes the following:

    CXXFLAGS += -DUSE_core_stub_in_nt_dll
    CXXFLAGS += -DUSE_core_stub_in_nt_dll_NOT_DEFINED_XXX

The first macro gets us dllimport for the included XXX.hh proxy stub.  The
second macro fools XXX.hh into undefining the first on exit, so that
compilation of the remainder of YYY.hh proceeds OK..  If you need multiple
base interfaces, then apply the undefinition macro on exit from the last .hh
you include but before the .hh for the DLL being built.

Of course you still have to do the normal .DEF file unpleasantness, but I
don't see Microsoft doing anything about this in the near future..

Ted Hayes



> -----Original Message-----
> From:	Renzo Tomaselli [SMTP:renzo.tomaselli@tecnotp.it]
> Sent:	Monday, December 03, 2001 3:54 PM
> To:	Omniorb list
> Subject:	[omniORB] packaging stubs in a dll
> 
> Hi all,
>     after including stubs directly into client/server code for years, we
> decided to package them into separate dll/shlib for economy reasons and to
> avoid the multiple proxyObjectFactory issue I mentioned in a previous
> message.
> Environment is OmniORB 3.04, NT/W2k, MSVC 6.0.
> OmniORB sources say to define the symbol "USE_stub_in_nt_dll" on client
> side
> before including IDL-generated include (.hh) files. This symbol forces
> import declaration of external symbols.
> This doesn't work when a module includes another one, and compilation
> fails.
> Indeed if we have module Foo including module Bar, stubs of Foo packaged
> into a dll behave as clients vs. Bar.
> Unfortunately the generated Foo.hh does not allow to have the above symbol
> undefined for Foo and defined for Bar.
> The final result is, according to definition of this symbol:
> - if defined in any case when compiling Foo stubs into a dll, the compiler
> complains about having declared some static members Foo as imported while
> they are actually defined locally;
> - if never defined, we get runtime access violations because it seems that
> some symbols (of static data, such as repoIDs) are left uninitialized if
> imported (while the linker seems to be happy anyway).
> Furthermore, if imported symbols are not declared as such, an extra
> indirection call occurs for all imported functions, according to MSDN.
> I think we need another symbol which should flag a specific IDL compiler
> output as either client or implementation side, to avoid import/export
> mismatch. And such a symbol should not propagate down along any import
> chain.
> Any comment ? Thanks,
>                                              Renzo Tomaselli
> --------------------------------------------------------------------------
> -
> TecnoTP s.n.c. Special Information System Design
> Maso Pelauchi I38050 Ronchi Valsugana,  Trento TN  ITALY
> Tel. +39 0461 773164      Fax. +39 0461 771514
> e-mail: renzo.tomaselli@tecnotp.it
> --------------------------------------------------------------------------
> -
> 
>