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

[Michael J. Donahue]

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