[omniORB] compiler error using GNU 2.95 on Solaris

[Smith, Norman]

Receiving a compile error when building omniORB_280pre1 under Solaris using
GNU 2.95 compiler:
 
---------------------
g++ -c  -fhandle-exceptions -Wall -Wno-unused  -DUsePthread -D_REENTRANT
-I. -I./.. -I./../.. -DUSE_omniORB_logStream -D_OMNIORB2_DYNAMIC_LIBRARY
-DUnixArchitecture -DCONFIG_DEFAULT_LOCATION=/etc/omniORB.cfg -I.
-I../../../../include -D__sparc__ -D__sunos__ -D__OSVERSION__=5 -o
irdynstub.o irdynstub.cc
cc1plus: warning: -fhandle-exceptions has been renamed to -fexceptions (and
is now on by default)
In file included from irdynstub.cc:34:
../irDynSK.cc: In function `Boolean
_0RL_tcParser_getElementDesc_s0_cstring(tcSequenceDesc *, long unsigned int,
tcDescriptor &)':
../irDynSK.cc:2997: initialization of non-const reference type `class
_CORBA_String_member &'
../irDynSK.cc:2997: from rvalue of type `_CORBA_String_member'
../../../../include/omniORB2/tcDescriptor.h:352: in passing argument 2 of
`_0RL_buildDesc_cstring(tcDescriptor &, _CORBA_String_member &)'
---------------------
 
The problem stems from a temporary (and therefore const) object being
generated and passed to the "_ORL_buildDesc_cstring" function which expects
a non-const object reference. The code fix I implemented to circumvent this
problem temporarily (although rather brute-force and inefficient) was the
following:
 
In modules irDynSK.cc, corbaidlDynSK.cc and bootstrapDynSK.cc:
 
static CORBA::Boolean
_0RL_tcParser_getElementDesc_s0_cstring(tcSequenceDesc* _desc, CORBA::ULong
_index, tcDescriptor& _newdesc)
{
// Original Code:
//   _0RL_buildDesc_cstring(_newdesc,
(*((_CORBA_Unbounded_Sequence__String*)_desc->opq_seq))[_index]);
// New Code:
  _CORBA_String_member theMember(
(*((_CORBA_Unbounded_Sequence__String*)_desc->opq_seq))[_index]  );
  _0RL_buildDesc_cstring(_newdesc, theMember);
// End New Code
  return 1;
}
 
My assumption is that this code is being generated by the IDL compiler
(hence the *DynSK.cc" nomenclature). I notice that others are using the GNU
2.95 compiler, but this problem has not been reported. Is there a patch to
the omniORB_280pre1 release that I need to install in order to resolve this
permanently?