[omniORB] omniORB3 BUG on NT compile

[David Riddoch]

Hi,


Thanks for that.  I've put the fix into CVS (yesterday, so you should be
able to get it right now).


David



On Fri, 22 Oct 1999, Ji-Yong D. Chung wrote:

> Omniorb Developers:
> 
>     I just managed to compile and DLL debug version of omniORB300_rtd.dll,
> with MSVC++ on NT4.0 (SP4).
> 
>     I linked it with omniNames object files and created omniNames.exe.  As
> soon as it begins to run for the FIRST time, it dies, due to "Unhandled
> exception in omniNames.exe ... Access Violation".   With David Riddoch's
> latest version, it is rather easy to build and reproduce the error.
> 
>     The error occurs inside log.cc, in
> 
>     omniNameslog::init(CORBA::ORB_ptr the_orb, PortableServer::POA_ptr the
> poa)
>     {
> 
>         // stuff
> 
>         putPort(port, logf);
>         {
>             CORBA::Object_var ref = poa_create_reference
>                 (   CosNaming::NamingContext::_PD_repoID);          <==
> ERROR happens here!!
>             PortableServer::ObjectID_var refid = poa -> reference_to_id(ref_
>         };
> 
>         // stuff
>     }
> 
> 
>     The variable CosNaming::NamingContext::_PD_repoID is exported from
> omniORB3 (one can see this in omniORB3.def file that is generated).
> 
>     That particular variable is used in omniNames (which is outside the
> omniORB3 dll).  This violates Microsoft requirement that, for exported
> variable to be used OUTSIDE the defining dll, the variable MUST be imported
> by the user module (with _declspec(dllimport) qualifier).  omniNames files
> do not import the variable (I checked it).  (By the way, this requirement is
> relaxed for functions imports).
> 
>     Without the import statement, the variable looks like unallocated memory
> to omniNames -- this is causing access error.
> 
> -------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>