On Fri, Nov 23, 2012 at 10:23 AM, Sylvain Joyeux <span dir="ltr">&lt;<a href="mailto:sylvain.joyeux@dfki.de" target="_blank">sylvain.joyeux@dfki.de</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<div><br></div><div>Would that work here too ?</div><div><br></div><div>Peter</div><div><br></div></div>