[omniORB] _narrow problems with VAC++ 5.0 on AIX

[Peter Ledbrook]

Yes, it is omniORB 2.8. In my frustration I forgot to mention that, sorry :-)

I am loading in a shared library using dlopen. The user has a choice of "solvers"
they can use, and the program will load in the particular one that the user has
chosen.

I assumed that _widenFromTheMostDerivedIntf should be called on
ICapeNumericLASystemFactory and so put a breakpoint there, but the program execution
seemed to bypass it. It does look like the virtual function handling failed in this
case.

Thanks for the help,

Peter

"Michael J. Donahue" wrote:

> This probably isn't related, but since Sai-Lai Lo mentioned stared libraries I
> figured it
> might be a good FYI.
>
> I have also noted problems using shared libraries on AIX 4.3 with Visual Age C++
> 5.0.
> In my case, I had to resort to using the static libraries to solve my problem.
> IMHO, it
> seems that when IBM wrote Visual Age C++ 5.0 they failed to update the linker to
> handle all of the changes that Visual Age C++ 5.0 brought to the table.
>
> - Mike Donahue
>
> Sai-Lai Lo <S.Lo@uk.research.att.com> on 07/28/2000 08:36:40 AM
>
> To:   Peter Ledbrook <p.ledbrook@psenterprise.com>
> cc:   omniorb-list@uk.research.att.com (bcc: Michael J. Donahue/MCLEOD)
> Subject:  Re: [omniORB] _narrow problems with VAC++ 5.0 on AIX
>
> I guess this is omniORB 2.8.
>
> >>>>> Peter Ledbrook writes:
>
> > Hi,
>
> > Much as I would like to give up supporting AIX, we are not allowed to.
> > So, can anyone help with this problem.
>
> > Part of an interface structure I have is:
>
> >     ICapeNumericSolverComponent
> >     ICapeNumericLAComponent : ICapeNumericSolverComponent
> >     ICapeNumericLASystemFactory : ICapeNumericLAComponent
>
> > Now, the client gets an object reference from a shared library that it
> > loads in. This object reference is an implementation of the
> > ICapeNumericLASystemFactory interface and has a repoID of:
>
> >   "IDL:ICapeNumericLASystemFactory:1.0"
>
> > The client then tries to narrow this to an
> > ICapeNumericSolverComponent_ptr with a repoID of:
>
> >   "IDL:ICapeNumericSolverComponent:1.0"
>
> > This narrow fails though, and returns a _nil object reference. Stepping
> > through the code of _realNarrow I see the following behaviour:
>
> > void*
> > omniObject::_realNarrow(const char* repoId)
> > {
> >   void* target = _widenFromTheMostDerivedIntf(repoId);  <<<<< This
> > returns 0x00000000
>   ^^^^^^^^^^^^^^^^^^^
>
>   This is not right! I suspect there is something wrong in the way the
>   compiler handle overloaded virtual function.
>
>   Please set a breakpoint at
>       ICapeNumericLASystemFactory::_widenFromTheMostDerivedIntf.
>
>  1. This function should be entered when _widenFromTheMostDerivedIntf is
>     called.
>  2. It should have taken the else branch and recursively called
>       ICapeNumericLAComponent::_widenFromTheMostDerivedIntf.
>  3. ICapeNumericLAComponent::_widenFromTheMostDerivedIntf should also
>     recursively called
>       ICapeNumericSolverComponent::_widenFromTheMostDerivedIntf
>     which decides this is a match and returns the this pointer.
>
> If the code doesn't do 1 to 3 then something is wrong with the generated
> code.
>
> I also notice that you said "the client gets an object reference from a
> shared library that it **loads in**". Do you mean the client program was
> linked with the shared library or does the client program do a dlopen to
> load the shared library? The later should also be suspected because the
> global static initializers in the shared library may not be called.
>
> Sai-Lai
>
> --
> 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

--
Product Development Engineer
Process Systems Enterprise Ltd.

Bridge Studios,
107a Hammersmith Bridge Road,
London
W6 9DA

Tel: +44 20 8563 0888   Fax: +44 20 8563 0999

mailto:p.ledbrook@psenterprise.com
website: http://www.psenterprise.com