[omniORB] omniORB 3 pre-release 3 is now available

Gary D. Duzan gdd0@gte.com
Mon, 03 Jul 2000 15:19:40 -0400


   Seems I was a bit hasty about the AIX build success. Shared
libraries aren't constructed properly. It is an easy fix, though:

Index: dir.mk
===================================================================
RCS file: /cvsroot/omni/src/lib/omniORB2/orbcore/sharedlib/dir.mk,v
retrieving revision 1.11.6.8
diff -r1.11.6.8 dir.mk
339c339
< NETLIBOBJS += gatekeeper.o
---
> ORB_OBJS += gatekeeper.o
===================================================================

The real fix is to build a generic export list for gatekeepers and
link that in, but until I have a need for them (or someone talks
me into it, or decides to do it themselves) the dummystub will have
to do.

					Gary Duzan
					GTE Laboratories
					Verizon Communications



In Message <200007031546.e63FkdQ02858@duzanmac.gte.com> ,
   "Gary D. Duzan" <gdd0@gte.com> wrote:

=>In Message <3o8zvjgu4l.fsf@neem.uk.research.att.com> ,
=>   Sai-Lai Lo <S.Lo@uk.research.att.com> wrote:
=>
=>=>Its a bug. The compiler missed out generating a static typecode value for the
=>=>sequence field member. (It does remember to generate one if it is other
=>=>types though..)
=>=>
=>=>Sigh! I thought we are closer to bug free by now :-) Glad you find this
=>=>now.
=>
=>   Sorry I didn't get to it earlier. My current project doesn't give
=>me much opportunity to work with CORBA. :-/
=>
=>=>I gather there is no build problem under AIX 4.2.1 and xlC 3.1.4?
=>
=>   Correct. It builds fine. Right now I'm trying to get our old
=>BOA app working with the compatability mode. Looks like I'll at
=>least have to change various debugging references to
=>SystemException::NP_RepositoryId to _NP_repoId.
=>
=>=>Sai-Lai
=>
=>					Gary Duzan
=>					GTE Laboratories
=>					Verizon Communications
=>
=>
=>
=>=>>>>>> Gary D Duzan writes:
=>=>
=>=>>    Under AIX 4.2.1 and xlC 3.1.4, I get this when compiling the
=>=>> one of our application stubs:
=>=>
=>=>> ===========================================================================
=>=>> "MPDyn.C", line 306.53: 1540-013: (S) "_0RL_tc_MPOSL_mType_mSlotType" is undefined.
=>=>> ===========================================================================
=>=>
=>=>> The code there looks like:
=>=>
=>=>> ===========================================================================
=>=>> static CORBA::PR_structMember _0RL_structmember_MP_mListObjectType[] = {
=>=>>   {"value_type", CORBA::TypeCode::PR_sequence_tc(1, _0RL_tc_MPOSL_mType_mSlotType)}
=>=>> };
=>=>> ===========================================================================
=>=>
=>=>> A glance through the MPOSL.idl header doesn't show this symbol,
=>=>> though there is this, which is close:
=>=>
=>=>> ===========================================================================
=>=>> // Declare helper class for union type MPOSL::Type::SlotType
=>=>> class _0RL_tcParser_unionhelper_MPOSL_mType_mSlotType;
=>=>> ===========================================================================
=>=>
=>=>> In case it isn't obvious, MPOSL::Type::SlotType is a union, and it
=>=>> is being referenced in MP.idl as the member type of a bounded(1)
=>=>> sequence.
=>=>
=>=>
=>=>-- 
=>=>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