[Bug 519] New: Unresolved symbols in KDL plugin

For more infomation about this bug, visit
Summary: Unresolved symbols in KDL plugin
Product: KDL
Version: kdl-trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Plugin
AssignedTo: orocos-dev [..] ...
ReportedBy: peter [dot] soetens [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

I tried to load the KDL plugins into an application and got the following
errors:

0.178 [ ERROR ][DeploymentComponent::loadLibrary] Could not load library
'/usr/local/orocos/lib/rtt/plugins/liborocos-kdltk-corba.so':
0.179 [ ERROR ][DeploymentComponent::loadLibrary]
/usr/local/orocos/lib/rtt/plugins/liborocos-kdltk-corba.so: undefined symbol:
_ZN7POA_RTT5Corba13BufferChannel5_is_aEPKc
0.190 [ ERROR ][DeploymentComponent::loadLibrary] Could not load library
'/usr/local/orocos/lib/rtt/plugins/liborocos-kdltk.so':
0.191 [ ERROR ][DeploymentComponent::loadLibrary]
/usr/local/orocos/lib/rtt/plugins/liborocos-kdltk.so: undefined symbol:
_ZN3KDL8Rotation3RPYEddd
0.192 [ ERROR ]

It seems that these libraries were not linked against libkdl and
liborocos-rtt-corba-gnulinux

$ ldd /usr/local/orocos/lib/rtt/plugins/liborocos-kdltk.so
linux-gate.so.1 => (0xffffe000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7cf2000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7ccd000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7cc1000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b77000)
/lib/ld-linux.so.2 (0x80000000)

As long as they are not linked correctly, they can not be loaded as plugins
into the deployment component.

Ruben Smits's picture

[Bug 519] Unresolved symbols in KDL plugin

For more infomation about this bug, visit

Ruben Smits <ruben [dot] smits [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
CC| |ruben [dot] smits [..] ...

--- Comment #3 from Ruben Smits <ruben [dot] smits [..] ...> 2008-02-29 12:09:08 ---
svn ci -m "Fixing bug #519: Unresolved symbols in KDL plugin, every
OROCOS_TARGET gets its own kdltk and kdltk-corba"
Sending src/bindings/rtt/CMakeLists.txt
Sending src/bindings/rtt/corba/CMakeLists.txt
Sending src/bindings/rtt/corba/orocos-kdltk-corba.pc.in
Sending src/bindings/rtt/kdltk.pc.in
Transmitting file data ....
Committed revision 29006.

Ruben

[Bug 519] Unresolved symbols in KDL plugin

For more infomation about this bug, visit

--- Comment #2 from Peter Soetens

<peter [dot] soetens [..] ...> 2008-02-27 16:15:09 ---
(In reply to comment #1)
> > As long as they are not linked correctly, they can not be loaded as plugins
> > into the deployment component.
> >
>
> It is very easy to solve. But the reason why i did not yet link the
> liborocos-kdltk to a version of liborocos-rtt is because i do not know if it is
> a problem to link against all target versions of liborocos-rtt or if i have to
> make tree different liborocos-kdltk-target libraries which contain the exact
> same code but only link with different liborocos-rtt versions.

The most clean solution is to make a kdltk for each target. You can not link
against more than one target.

Peter

Ruben Smits's picture

[Bug 519] Unresolved symbols in KDL plugin

For more infomation about this bug, visit

Ruben Smits <ruben [dot] smits [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
Status|NEW |ASSIGNED
Target Milestone|--- |1.0.0

--- Comment #1 from Ruben Smits <ruben [dot] smits [..] ...> 2008-02-25 08:57:20 ---
[...]
>
> It seems that these libraries were not linked against libkdl and
> liborocos-rtt-corba-gnulinux
>
> $ ldd /usr/local/orocos/lib/rtt/plugins/liborocos-kdltk.so
> linux-gate.so.1 => (0xffffe000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7cf2000)
> libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7ccd000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7cc1000)
> libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b77000)
> /lib/ld-linux.so.2 (0x80000000)
>
> As long as they are not linked correctly, they can not be loaded as plugins
> into the deployment component.
>

It is very easy to solve. But the reason why i did not yet link the
liborocos-kdltk to a version of liborocos-rtt is because i do not know if it is
a problem to link against all target versions of liborocos-rtt or if i have to
make tree different liborocos-kdltk-target libraries which contain the exact
same code but only link with different liborocos-rtt versions.

Ruben