[omniORB] Tripping over omniORB non-ANSI code using Sun nativ e v5.0 compiler

[Smith, Norman]

Thanks, Bjorn.

I agree that this error is a result of some Sun compiler issue, as one of
the other guys on my project has seen this same error when using some
combination of virtual destructors (unfortunately he can't remember the
exact scenario).  I'll keep hammering at it. I've tried generating some
smaller test code to mimic the problem so I can make Sun aware of it, but
haven't been able to duplicate the error yet.

What puzzles me is that omniORB tech support says that they have gotten a
successful build out of the same compiler. We have downloaded and installed
all of the latest patches from Sun, and so should be up to date. (Maybe
that's the problem, and we're ahead of omniORB developers on the platform
compiler.)

P.S. I grep'ed the entire src and include trees for the declaration of the
AST_Decl class, but couldn't find anything except the definition in the ast
subdirectory, and the reference in the omniidl2 tree. Where is it?

-----Original Message-----
From: Bjorn Wennberg [mailto:bjornw@tihlde.org]
Sent: Thursday, July 15, 1999 5:16 AM
To: Smith, Norman
Cc: 'Tom Dube'; omniorb-list@uk.research.att.com
Subject: Re: [omniORB] Tripping over omniORB non-ANSI code using Sun
nativ e v5.0 compiler


"Smith, Norman" <Norman_Smith@bmc.com> writes:

> I have done some research into the source code, and the problem seems to
> hinge around the destructor definition in class "o2be_sequence_chain" in
> file "<top>/src/tool/omniidl2/omniORB2_be/o2be.h". Removing the virtual
> declaration in its entirety solves the SLIP.DELETER problem, and allows
> omniidl2 to build. 
> 
> Alas, after this the compiler gets what appears to be a SIGSEGV
(Signal=11)
> violation and aborts. I don't know if it has to do with the removal of the
> aforementioned virtual destructor or not. I've tried several variations on
> the destructor for that class (making it non-virtual, adding a line of
code
> into the body, etc.), but the only thing that seems to satisfy the
> SLIP.DELETER problem is to remove it entirely.

To me this sounds like a compiler bug.

I think your compiler has a bug using virtual inheritance.

Removing the 'virtual' before the dtor in o2be_name should not cause
any harm since its base class, AST_Decl, has virtual dtor and thus
all dtors in the derived class will be automatically declared as virtual.
I've tested that for egcs and vc++ 6.0.

I'm not that familliar with the code to say what will happen if you
remove the virtual inheritance though :-/

bjornw>