[omniORB] Unresolved symbol on HPUX: unixTransportDirectory__ Q2_4omni13orbParameters

Tingle, Alex Alex.Tingle at bronermetals.com
Mon Jan 12 15:28:31 GMT 2004


It's a bug in 4.0.1. You need to upgrade to 4.0.2+ for a fix.

-Alex
 

-----Original Message-----
From: Frederic Prin [mailto:frederic.prin at silvaco.com]
Sent: 08 January 2004 14:37
To: omniorb-list at omniorb-support.com
Subject: [omniORB] Unresolved symbol on HPUX:
unixTransportDirectory__Q2_4omni13orbParameters 


Hi all,

Can someone tell me why I have this unresolved symbol when building my app
with omniORB-4.0.1 on HPUX ?
or which omni* lib defines this symbol ?

/usr/lib/dld.sl: Unresolved symbol:
unixTransportDirectory__Q2_4omni13orbParameters (data)  from
/main/frlocal/programs/omniORB-4.0.1/hp700-hpux901/lib/libomniORB4.sl.0

nm tells that it is really undef :
nm /main/frlocal/programs/omniORB-4.0.1/hp700-hpux901/lib/libomniORB4.sl.0 |
grep unixTransportDirectory | grep Parameters
unixTransportDirectory__Q2_4omni13orbParameters|          |undef |data   |



Thanks for your help



-----Original Message-----
From: omniorb-list-bounces at omniorb-support.com
[mailto:omniorb-list-bounces at omniorb-support.com] On Behalf Of Rolf C
Stadheim
Sent: mercredi 7 janvier 2004 17:33
To: omniorb-list at omniorb-support.com
Subject: [omniORB] Is it imperative to keep client and server interface
insync?


I was wondering how important it is to keep the stubs and skeletons in sync,
between client and server?

That is, suppose one have the following original interface:

mudule test
{
    interface someObj
    {
           void someMethod1();
    }
}

The stubs and skeletons for the client and servant (both C++) are generated,
and all is well.

Now suppose the interface gets one more method:

mudule test
{
    interface someObj
    {
           void someMethod1();
           void someMethod2();
    }
}

and the stubs are generated, and the client is compiled and linked with
these new stubs. The servant is unchanged.

Now, if I use this new client, but only call the original someMethod1() (the
servant naturally does not know anything about someMethod2()), what are the
consequences, if any?

Access violation, systems exception, or will this work fine as long as the
client does not call the new method?

Regards,
Rolf C Stadheim



More information about the omniORB-list mailing list