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

[Sai-Lai Lo]

Smith,

I've seen the SLIP.DELETER problem with omniidl2 and have managed to make
it built by rearranging the base class structure in ast_decl.hh. However
this does not help because as you have found out, the result binary does
not run. I've reported this to Sun's support and end up talking to someone
who hasn't got a clue and kept asking for a small test case before they
will look into it. I gave up because I don't want to waste time to
debug a compiler. For the same reason I gave up on a commercial ORB a few
years back because compiler and middleware are the components you want to
trust to do the right thing even if you occasionally do something stupid.
Otherwise it is a debugging nightmare.

In the end, the compiler was patched to the latest patch level (see
README.SunC++5). As long as you use -g or '-O2 -g', it seems to work OK.

If you can manage to produce a small test case to submit to Sun so that
they can fix the problem you are most welcomed! Otherwise, it is not worth
trying to workaround the bug by modifying the source because I'm sure Sun
has to significantly improve the quality of their compiler quickly if they
are serious about supporting C++ customers to move to standard C++.

Sai-Lai
 


>>>>> Smith, Norman 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.

> 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.



-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND