[Rock-dev] Deploying an Orogen component from the OCL Deployer

[Peter Soetens]

On Fri, Nov 23, 2012 at 10:23 AM, Sylvain Joyeux <sylvain.joyeux at dfki.de>wrote:

> On 11/23/2012 07:49 AM, Charles Lesire-Cabaniols wrote:
> > Hi,
> >
> > I have created an Orogen component and I try to deploy it with the OCL
> > Deployer.
> > The component is correctly loaded, but its associated typekit is not!
> >
> > For instance, with the MessageProducer component (from the first Rock
> > tutorials), the deployer complains that:
> >
> > ~/work/rock$ deployer-gnulinux
> > 0.102 [ ERROR  ][DeploymentComponent::configure] Could not load
> > library
> >
> '/home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so':
> > 0.103 [ ERROR  ][DeploymentComponent::configure]
> >
> /home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
> > undefined symbol: _ZN11omni_thread6init_tD1Ev
> > 0.174 [ ERROR  ][DeploymentComponent::configure] could not load
> > library
> >
> '/home/lesire/work/rock/install/lib/orocos/types/libmessage_producer-typekit-gnulinux.so':
> >
> /home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
> > undefined symbol: _ZN11omni_thread6init_tD1Ev
> >
> > And then the message_procuder types and unknown.
> >
> > The symbol is not defined because the typekit does not link to any
> > omniorb library, which is a good thing anyway!
> >
> > Any idea how to fix it?
> Two issues here:
>   - the deployer tries to load the port_proxy tasks. Are you actually
> trying to really load it ? Can you check whether
> message_producer-tasks-gnulinux links to port_proxy-tasks-gnulinux ?
>   - the port_proxy tasks should link to corba libraries because,
> unfortunately, "someone" decided to add some corba name resolution stuff
> in there (/me takes his big fluffy hammer and goes to friendly hit that
> "someone").
>

There was a similar issue with the TaskContextProxy/Server headers in rtt,
pulling in omniorb symbols. We accepted a patch to create a rtt header
which won't cause the client to include corba headers and hence don't link
with the omniorb libraries, but only to the orocos-rtt-corba library. As
such, client code was free of the specific corba implementation.

Would that work here too ?

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20121123/7dc8bed1/attachment.htm