[omniORB] VMS and Oracle (Re: Compaq C++ 5.6 bugs)

Visscher, Bruce VISSCHB@RJRT.com
Thu, 30 Mar 2000 10:38:36 -0500


[I sent this message out earlier but it didn't get through because of SMTP
problems.  Sorry for the delay.]

> Viktor,
> 
> Viktor Groth wrote:
> > 
> > Bruce,
> > 
> > thank you for your explanations about the compilers. I would like to use
> > omniORB and Oracle modules in one application. As far as I know, the most
> > recent Oracle version is 8.0.5 and Oracle supports only C++ 5.6 (The build
> > failed, when I tried once with a higher compiler version (I do not remeber
> > what version it was)). So I have to stick to 5.6.
> 
> The only real problem that I know of here is the memory leak in the exception
> handling code.  I would expect Compaq to fix this for the VAX platform since
> upgrading to 6.0 or later is not an option, but I don't know if they will for
> Alpha (since they could argue that you should upgrade).  It's a fairly slow
> leak, so perhaps you could work around it.
> 
> Theoretically, you can install a 6.x compiler and "keep" the 5.6 compiler (this
> is an install option).  IMHO, this could get messy and might not work
> indefinitely.  We did this and it worked at first but now I get errors from the
> command tables if I try to use the old compiler.
> 
> Also, regarding the build errors, were these compile errors?  Did you try
> compiling with /Quiet?
> 
> > I tried to build an application with omniORB and Oracle (ProC) modules.
> > The compile and link (omniORB 2.7.1) worked without errors or warnings.
> > But when I run the application, I get an access violation (I do not even
> > see any function in the dump message). When I use the debugger, the app
> > crashes in an oracle function (actually when connecting to the database).
> > 
> > Does anybody use Oracle (ProC) modules with omniORB successfully?
> 
> I don't know this product.  Is there a thread safety issue?
> 
> > My other C/C++ modules are compiled with the qualifier
> > /extern_model=common /share_globals. Is it ok to link modules with this
> > options with omniORB?
> 
> I am not aware of any problems in doing this as long as you are consistent. 
> I.e., you might need to build the omniORB libraries with the same qualifiers. 
> On Alpha the default is /extern_model=strict_refdef/noshare, but this is
> primarily for building shareable images.  In fact, it's kind of a hack: I do
> this just to force certain external references to appear in a library listing. 
> If you don't do this you get weak references which are more difficult to find.
> 
> HTH,
> 
> Bruce