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

[Smith, Norman]

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.

I'm still trying to determine how this particular class is being used (i.e.
super- or sub-classed) to cause a problem with this destructor. If you are
able to obtain any info or can offer another suggestion, I'd be happy to
hear it.


-----Original Message-----
From: Tom Dube [mailto:tdube@caminus.com]
Sent: Tuesday, July 13, 1999 8:44 AM
To: Smith, Norman
Subject: RE: [omniORB] Tripping over omniORB non-ANSI code using Sun
native v5.0 compiler


At 05:49 PM 7/12/99 -0500, you wrote:
>Yes, this was the original problem for me also. Support says to make sure
>the latest compiler patches are installed. Unless there are some
>undocumented patches I don't know about, we have all the patches and get
the
>error anyway.

I believe that our compiler patches are up-to-date as well.

Do you know if this is a compiler bug or a problem with omniORB?

>Our work around at this point is using GNU 2.8.1 compiler on Sun platform
>until we can get these other issues resolved.

Unfortunately, we don't have that option.   We are dependent on some
third-party libraries which only link using sparcworks.

-Tom