[omniORB] Re: Windows NT and dllimport/dllexport

[Sai-Lai Lo]

I like to know more about your problem.

Firstly, let me explain the recommended steps to compile and use the stubs
in DLLs:

1. To compile:
     a) *SK.cc stub files,
           Specify the CPP flag -DUse_dyn_stub_in_nt_dll
                                 ^^^^^^^^^^^^^^^^^^^^^^^
                                 This put dllimport on the relevant symbols
                                 exported by *DynSK.cc files.

     b) *DynSK.cc stub files,
           Specify the CPP flag -DUse_core_stub_in_nt_dll

        The flags will cause the right dllimport to be added when compiling
        the stubs.

     c) We don't use dllexport in the stub as we found that it didn't do
        the right thing with template classes. The result is that some of
        the symbols are not exported.
        Instead, we create a .def file to export the symbols.
        The .def file is generated based on the output of dumpbin.
        For example, this is a gnumake canned command to autogenerate the
        .def file. 

# MakeCXXExportSymbolDefinitionFile
#
#  - Create a .def file containing all the functions and static class 
#    variables exported by the DLL. The symbols are extracted from the 
#    output of dumpbin.
#
#    The function symbols are extracted using the following template:
#    ... ........ SECT..  notype ()     External      | ?..................
#
#    The static class variable symbols are extracted using the following
#    template:
#    ... ........ SECT..  notype        External      | ?[^?]..............
#
#    Default destructors generated by the compiler are excluded.
#
#    It looks like class variable and function symbols start with two ??
#    and class static variable and static function symbols start with one ?.
#                                                             - SLL
#
define MakeCXXExportSymbolDefinitionFile
symreflib=$(SharedLibrarySymbolRefLibraryTemplate); \
set -x; \
echo "LIBRARY $$libname" > $$defname; \
echo "VERSION $$version" >> $$defname; \
echo "EXPORTS" >> $$defname; \
DUMPBIN.EXE /SYMBOLS $$symreflib | \
egrep '^[^ ]+ +[^ ]+ +SECT[^ ]+ +[^ ]+ +\(\) +External +\| +\?[^ ]*|^[^ ]+ +[^ ]+ +SECT[^ ]+ +[^ ]+ +External +\| +\?[^?][^ ]*'|\
egrep -v 'deleting destructor[^(]+\(unsigned int\)' | \
cut -d'|' -f2 | \
cut -d' ' -f2 | $(SORT) -u >> $$defname; \
set +x;
endef


2. To use:
      Specify the CPP flags -DUse_stub_in_nt_dll.
      This is equivalent to both -DUse_dyn_stub_in_nt_dll and
                                 -DUse_core_stub_in_nt_dll
      together.

Could you try the above and tell me if your problem goes away?

Sai-Lai


>>>>> John A Byerly writes:

> I have recently downloaded omniORB 3.0.0.  Our project was using 2.7.1.  I
> was in the process of migrating to the newer version and got stuck on a
> problem.

> Most of our code is compiled into a DLL.  To facilitate this, we use the
> following:

> #ifdef THIS_IS_MY_DLL
> #define CLASS_DECL declspec(dllexport)
> #else
> #define CLASS_DECL declspec(dllimport)
> #endif
> class CLASS_DECL MyClass
> ...

> THIS_IS_MY_DLL is defined when the DLL is compiled, and is not defined for
> entities that will link to the DLL.

> Until 3.0.0, we had no problems with the CORBA code.  Now, I am getting an
> unresolved external for one of the class members generated by omniidl.  I
> fixed the problem by modifying the generated code to include the #defines
> shown above.  Obviously, this is not a desirable fix.

> Is there any way to get the #defines into the generated code through
> omniidl?  Or is there a better way around this problem?



-- 
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