[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