[omniORB] Unresolved symbol on HPUX: unixTransportDirectory__Q2_4omni13orbParameters

[Frederic Prin]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20040108/e15fb011/attachment.htm