OCL cross compil problem and RTT compil warning

Submitted by Polch on Tue, 2010-12-14 15:50

Hi.

When i compile RTT 2.2.0 i have this warning :

Quote:

sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp: In static member function 'static RTT::base::ChannelElementBase::shared_ptr RTT::internal::ConnFactory::createRemoteConnection(RTT::base::OutputPortInterface&, RTT::base::InputPortInterface&, const RTT::ConnPolicy&)': sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp:83:16: warning: converting 'false' to pointer type for argument 1 of 'boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T = RTT::base::ChannelElementBase]' sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp:89:16: warning: converting 'false' to pointer type for argument 1 of 'boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T = RTT::base::ChannelElementBase]'

When i compile OCL 2.2.0 i have these error (it's a cross compilation case see below) :

Quote:

-- Optional library RTT_PLUGIN_rtt-scripting NOT FOUND. If the library is already installed, use the RTT_PLUGIN_rtt-scripting_ROOT_DIR environment variable or ccmake to set the missing variables manually. -- Optional library RTT_PLUGIN_rtt-marshalling NOT FOUND. If the library is already installed, use the RTT_PLUGIN_rtt-marshalling_ROOT_DIR environment variable or ccmake to set the missing variables manually.

and later

Quote:

TaskBrowser.cpp:(.text+0x4a22): undefined reference to `RTT::scripting::Parser::Parser(RTT::TaskContext*)' ...

Would it be possible to compile without manually defining RTT_PLUGIN_rtt-scripting_ROOT_DIR ? As i cross compile i use a CMAKE_INSTALL_PREFIX that refer to a target path and an OROCOS_INSTALL that refer to an host path. Is there any mistake ?

Thank for your help.

Paul.

OCL cross compil problem and RTT compil warning

Submitted by peter on Wed, 2010-12-15 09:20.

On Tuesday 14 December 2010 16:50:23 paul [dot] chavent [..] ... wrote:
> Hi.
>
> When i compile RTT 2.2.0 i have this warning :
>
>

Quote:

> sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp: In static member
> function 'static RTT::base::ChannelElementBase::shared_ptr
> RTT::internal::ConnFactory::createRemoteConnection(RTT::base::OutputPortIn
> terface&, RTT::base::InputPortInterface&, const RTT::ConnPolicy&)':
> sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp:83:16: warning:
> converting 'false' to pointer type for argument 1 of
> 'boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T =
> RTT::base::ChannelElementBase]'
> sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp:89:16: warning:
> converting 'false' to pointer type for argument 1 of
> 'boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T =
> RTT::base::ChannelElementBase]'

Thanks for reporting. I've pushed the fix.

>
> When i compile OCL 2.2.0 i have these error (it's a cross compilation case
> see below) :
>
>

Quote:

> -- Optional library RTT_PLUGIN_rtt-scripting NOT FOUND. If the library is
> already installed, use the RTT_PLUGIN_rtt-scripting_ROOT_DIR environment
> variable or ccmake to set the missing variables manually. -- Optional
> library RTT_PLUGIN_rtt-marshalling NOT FOUND. If the library is already
> installed, use the RTT_PLUGIN_rtt-marshalling_ROOT_DIR environment
> variable or ccmake to set the missing variables manually.

The error message is not correct. It searches in the ${OROCOS-RTT_PLUGIN_PATH}
which has been set by the find_package(OROCOS-RTT) macro. So if OROCOS-RTT has
been found, this path should be set and the plugins should be found.

>
> and later
>
>

Quote:

> TaskBrowser.cpp:(.text+0x4a22): undefined reference to
> `RTT::scripting::Parser::Parser(RTT::TaskContext*)' ...
>

>
> Would it be possible to compile without manually defining
> RTT_PLUGIN_rtt-scripting_ROOT_DIR ? As i cross compile i use a
> CMAKE_INSTALL_PREFIX that refer to a target path and an OROCOS_INSTALL
> that refer to an host path. Is there any mistake ?

I don't think you made a mistake. All paths are derived (relative to) from the
location of the orocos-rtt-config.cmake file. So if this file is found,
everything else should be ok, regardless of where you actually installed or
*how* it was installed. We don't hard-code the install path in our cmake files.
We deduce it from the actual location of orocos-rtt-config.cmake. This is the
whole logic of setting the paths:

# Path to current file
get_filename_component(SELF_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
# Default component search path
get_filename_component(OROCOS-RTT_PATH "${SELF_DIR}/../../.." ABSOLUTE)
get_filename_component(OROCOS-RTT_COMPONENT_PATH 
"${SELF_DIR}/../../../lib/orocos${OROCOS_SUFFIX}" ABSOLUTE)
get_filename_component(OROCOS-RTT_PLUGINS_PATH 
"${SELF_DIR}/../../../lib/orocos${OROCOS_SUFFIX}/plugins" ABSOLUTE)
get_filename_component(OROCOS-RTT_TYPES_PATH   
"${SELF_DIR}/../../../lib/orocos${OROCOS_SUFFIX}/types"   ABSOLUTE)
 
list(APPEND OROCOS-RTT_PLUGIN_PATH "${OROCOS-RTT_PLUGINS_PATH}"
                                      "${OROCOS-RTT_TYPES_PATH}")
 
# Append additional user-defined plugin search paths
foreach(CUSTOM_PLUGIN_PATH $ENV{RTT_COMPONENT_PATH})
  list(APPEND OROCOS-RTT_PLUGIN_PATH "${CUSTOM_COMPONENT_PATH}/plugins"
                                        "${CUSTOM_COMPONENT_PATH}/types")
endforeach()
# Append additional user-defined component search paths
foreach(CUSTOM_COMPONENT_PATH $ENV{RTT_COMPONENT_PATH})
  list(APPEND OROCOS-RTT_COMPONENT_PATH "${CUSTOM_COMPONENT_PATH}")
endforeach()

So it's still a bit of a mystery to me...

Peter

Hello.I have found the

Submitted by Polch on Fri, 2010-12-17 16:00.

Hello.

I have found the problem.

I have a CMAKE_TOOLCHAIN_FILE where i define

# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

I don't want to set "BOTH" to make sure that the host system have no impact on the target.

So there is a problem when orocos cmake scripts try to find plugins library with provided path.

I give you two patches that partially correct the problem and allow me to detect the scripting and marshalling service when i compile ocl.

Though, i still have a problem when linking the deployer.

/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-linux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld: warning: librtt-marshalling-gnulinux.so.2.2.0, needed by ../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using -rpath or -rpath-link)
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-linux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld: warning: librtt-scripting-gnulinux.so.2.2.0, needed by ../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using -rpath or -rpath-link)

Perhaps it lacks a LINK_LIBRARY_PATH ?

I'am not sure that those patches are the best solution. So give me your opinion please.

Paul.

Hello.I have found the

Submitted by Polch on Fri, 2010-12-17 15:58.

Hello.

I have found the problem.

I have a CMAKE_TOOLCHAIN_FILE where i define

# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

I don't want to set "BOTH" to make sure that the host system have no impact on the target.

So there is a problem when orocos cmake scripts try to find plugins library with provided path.

I give you two patches that partially correct the problem and allow me to detect the scripting and marshalling service when i compile ocl.

Though, i still have a problem when linking the deployer.

/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-linux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld: warning: librtt-marshalling-gnulinux.so.2.2.0, needed by ../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using -rpath or -rpath-link)
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-linux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld: warning: librtt-scripting-gnulinux.so.2.2.0, needed by ../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using -rpath or -rpath-link)

Perhaps it lacks a LINK_LIBRARY_PATH ?

I'am not sure that those patches are the best solution. So give me your opinion please.

Paul.

Hello.I have found the

Submitted by phamelin on Mon, 2010-12-20 13:12.

> Though, i still have a problem when linking the deployer.
>
>

>
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-linux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld:
warning: librtt-marshalling-gnulinux.so.2.2.0, needed by
../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using
-rpath or -rpath-link)
>
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-linux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld:
warning: librtt-scripting-gnulinux.so.2.2.0, needed by
../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using
-rpath or -rpath-link)
>

>
> Perhaps it lacks a LINK_LIBRARY_PATH ?
>
>
> I'am not sure that those patches are the best solution. So give me your
opinion please.
>
>

I just want to mention that I had the same problem when cross compiling for
ppc. I didn't had time to look further yet but I had the same preliminary
conclusions. Also, this was working in 2.0 before the changes for ros were
integrated in the deployer cmake file. You may find a post from me about
that in the archive.

Philippe

OCL cross compil problem and RTT compil warning

Submitted by Polch on Mon, 2011-01-03 17:04.

Happy new year to the orocos people !

Philippe.

I've read your previous post, i don't think it is a problem of the appending of TARGET_NAME.

Peter.

I also think it is a problem of rpath.
I need your help to go further.

Here is the log of the compilation of liborocos-deployment-gnulinux.so and cdeployer-gnulinux

Linking CXX shared library liborocos-deployment-gnulinux.so
cd /home/ressac/work/pip22/sdk/builds/orocos-ocl-2.2.0/deployment && /usr/bin/cmake -E cmake_link_script CMakeFiles/orocos-deployment.dir/link.txt --verbose=1
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/i686-pip22-linux-gnu-g++  -fPIC -O3 -DNDEBUG -Wl,-z,defs -shared -Wl,-soname,liborocos-deployment-gnulinux.so.2.2.0 -o liborocos-deployment-gnulinux.so.2.2.0 CMakeFiles/orocos-deployment.dir/DeploymentComponent.cpp.o CMakeFiles/orocos-deployment.dir/ComponentLoader.cpp.o CMakeFiles/orocos-deployment.dir/comppath.cpp.o -L/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/liborocos-rtt-gnulinux.so.2.2.0 -ldl /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/orocos/plugins/librtt-marshalling-gnulinux.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/orocos/plugins/librtt-scripting-gnulinux.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_filesy
 stem-mt.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_system-mt.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_serialization-mt.so -lpthread -lrt -ldl -Wl,-rpath,/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/orocos/plugins:/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib::::::::::::: 
cd /home/ressac/work/pip22/sdk/builds/orocos-ocl-2.2.0/deployment && /usr/bin/cmake -E cmake_symlink_library liborocos-deployment-gnulinux.so.2.2.0 liborocos-deployment-gnulinux.so.2.2.0 liborocos-deployment-gnulinux.so
 
 
[...]
 
 
Linking CXX executable cdeployer-gnulinux
cd /home/ressac/work/pip22/sdk/builds/orocos-ocl-2.2.0/bin && /usr/bin/cmake -E cmake_link_script CMakeFiles/cdeployer-gnulinux.dir/link.txt --verbose=1
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/i686-pip22-linux-gnu-g++   -O3 -DNDEBUG   CMakeFiles/cdeployer-gnulinux.dir/cdeployer.cpp.o CMakeFiles/cdeployer-gnulinux.dir/deployer-funcs.cpp.o  -o cdeployer-gnulinux -rdynamic -L/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/liborocos-rtt-gnulinux.so.2.2.0 /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/liborocos-rtt-corba-gnulinux.so.2.2.0 ../deployment/liborocos-deployment-corba-gnulinux.so.2.2.0 /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_program_options-mt.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/liborocos-rtt-corba-gnulinux.so.2.2.0 /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys
 -root/usr/lib/libomniORB4.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libomniDynamic4.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libomnithread.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libCOS4.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libCOSDynamic4.so ../deployment/liborocos-deployment-gnulinux.so.2.2.0 /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/liborocos-rtt-gnulinux.so.2.2.0 /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_filesystem-mt.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_system-mt.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sy
 s-root/usr/lib/libboost_serialization-mt.so -lpthread -lrt -ldl -Wl,-rpath,/home/ressac/work/pip22/sdk/builds/orocos-ocl-2.2.0/deployment:/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib: 
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-linux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld: warning: librtt-marshalling-gnulinux.so.2.2.0, needed by ../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using -rpath or -rpath-link)
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-linux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld: warning: librtt-scripting-gnulinux.so.2.2.0, needed by ../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using -rpath or -rpath-link)
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyLoader::configure(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, RTT::TaskContext*, bool) const'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyDemarshaller::deserialize(RTT::PropertyBag&)'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyDemarshaller::~PropertyDemarshaller()'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyLoader::save(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, RTT::TaskContext*, bool) const'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyDemarshaller::PropertyDemarshaller(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::Scripting::Scripting(RTT::TaskContext*)'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `typeinfo for RTT::Scripting'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyLoader::load(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, RTT::TaskContext*) const'
collect2: ld returned 1 exit status

I can't find how the rpath of the compilation of liborocos-deployment-gnulinux.so is built. The lacks of the lib/orocos/plugins rpath in the compilation of cdeployer-gnulinux is probably the origin of my problem. So i would like to know how it is build for the deployment lib to adapt for the binary build.

Thanks for your help.

Paul.

OCL cross compil problem and RTT compil warning

Submitted by Polch on Tue, 2011-01-04 13:05.

Hi.

For temporary fixing these problem, i use those patches.

Regards.

OCL cross compil problem and RTT compil warning

Submitted by Polch on Mon, 2011-01-03 17:01.

Happy new year to the orocos people !

Philippe.

I've read your previous post, i don't think it is a problem of the appending of TARGET_NAME.

Peter.

I also think it is a problem of rpath. I need your help to go further.

Here is the log of the compilation of liborocos-deployment-gnulinux.so and cdeployer-gnulinux

Linking CXX shared library liborocos-deployment-gnulinux.so
cd /home/ressac/work/pip22/sdk/builds/orocos-ocl-2.2.0/deployment && /usr/bin/cmake -E cmake_link_script CMakeFiles/orocos-deployment.dir/link.txt --verbose=1
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/i686-pip22-linux-gnu-g++  -fPIC -O3 -DNDEBUG -Wl,-z,defs -shared -Wl,-soname,liborocos-deployment-gnulinux.so.2.2.0 -o liborocos-deployment-gnulinux.so.2.2.0 CMakeFiles/orocos-deployment.dir/DeploymentComponent.cpp.o CMakeFiles/orocos-deployment.dir/ComponentLoader.cpp.o CMakeFiles/orocos-deployment.dir/comppath.cpp.o -L/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/liborocos-rtt-gnulinux.so.2.2.0 -ldl /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/orocos/plugins/librtt-marshalling-gnulinux.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/orocos/plugins/librtt-scripting-gnulinux.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_filesystem-mt.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_system-mt.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_serialization-mt.so -lpthread -lrt -ldl -Wl,-rpath,/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/orocos/plugins:/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib::::::::::::: 
cd /home/ressac/work/pip22/sdk/builds/orocos-ocl-2.2.0/deployment && /usr/bin/cmake -E cmake_symlink_library liborocos-deployment-gnulinux.so.2.2.0 liborocos-deployment-gnulinux.so.2.2.0 liborocos-deployment-gnulinux.so
 
 
[...]
 
 
Linking CXX executable cdeployer-gnulinux
cd /home/ressac/work/pip22/sdk/builds/orocos-ocl-2.2.0/bin && /usr/bin/cmake -E cmake_link_script CMakeFiles/cdeployer-gnulinux.dir/link.txt --verbose=1
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/i686-pip22-linux-gnu-g++   -O3 -DNDEBUG   CMakeFiles/cdeployer-gnulinux.dir/cdeployer.cpp.o CMakeFiles/cdeployer-gnulinux.dir/deployer-funcs.cpp.o  -o cdeployer-gnulinux -rdynamic -L/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/liborocos-rtt-gnulinux.so.2.2.0 /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/liborocos-rtt-corba-gnulinux.so.2.2.0 ../deployment/liborocos-deployment-corba-gnulinux.so.2.2.0 /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_program_options-mt.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/liborocos-rtt-corba-gnulinux.so.2.2.0 /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libomniORB4.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libomniDynamic4.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libomnithread.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libCOS4.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libCOSDynamic4.so ../deployment/liborocos-deployment-gnulinux.so.2.2.0 /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/i686-pip22-linux-gnu/sys-root/usr/lib/liborocos-rtt-gnulinux.so.2.2.0 /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_filesystem-mt.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_system-mt.so /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib/libboost_serialization-mt.so -lpthread -lrt -ldl -Wl,-rpath,/home/ressac/work/pip22/sdk/builds/orocos-ocl-2.2.0/deployment:/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/bin/../i686-pip22-linux-gnu/sys-root/usr/lib: 
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-linux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld: warning: librtt-marshalling-gnulinux.so.2.2.0, needed by ../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using -rpath or -rpath-link)
/home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-linux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld: warning: librtt-scripting-gnulinux.so.2.2.0, needed by ../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using -rpath or -rpath-link)
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyLoader::configure(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, RTT::TaskContext*, bool) const'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyDemarshaller::deserialize(RTT::PropertyBag&)'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyDemarshaller::~PropertyDemarshaller()'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyLoader::save(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, RTT::TaskContext*, bool) const'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyDemarshaller::PropertyDemarshaller(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::Scripting::Scripting(RTT::TaskContext*)'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `typeinfo for RTT::Scripting'
../deployment/liborocos-deployment-gnulinux.so.2.2.0: undefined reference to `RTT::marsh::PropertyLoader::load(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, RTT::TaskContext*) const'
collect2: ld returned 1 exit status

Thanks for your help.

Paul.

OCL cross compil problem and RTT compil warning

Submitted by Polch on Tue, 2011-01-04 13:08.

Hi.

For temporary fixing these problem, i use those patches.

Regards.

Hello.I have found the

Submitted by peter on Mon, 2010-12-20 09:04.

On Friday 17 December 2010 16:58:47 paul [dot] chavent [..] ... wrote:
> Hello.
>
> I have found the problem.
>
> I have a CMAKE_TOOLCHAIN_FILE where i define
>
>

> # for libraries and headers in the target directories
> SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>

>
> I don't want to set "BOTH" to make sure that the host system have no impact
> on the target.

So what happens is that when you install orocos in /target/orocos, it will
look for the plugins in /target/orocos/target/orocos, because it prepends a
root-path to all search paths ?

>
> So there is a problem when orocos cmake scripts try to find plugins library
> with provided path.
>
> I give you two patches that partially correct the problem and allow me to
> detect the scripting and marshalling service when i compile ocl.

We could try to clear the root path for that find instruction, since it's
already a full path. So setting NO_CMAKE_FIND_ROOT_PATH might be better in
this case than your solution.

>
> Though, i still have a problem when linking the deployer.

Is this the output from linking the deployer application or library ??

>
>

> /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-lin
> ux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld: warning:
> librtt-marshalling-gnulinux.so.2.2.0, needed by
> ../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using
> -rpath or -rpath-link)
> /home/ressac/work/pip22/sdk/toolchain_root/opt/pip22/lib/gcc/i686-pip22-li
> nux-gnu/4.5.1/../../../../i686-pip22-linux-gnu/bin/ld: warning:
> librtt-scripting-gnulinux.so.2.2.0, needed by
> ../deployment/liborocos-deployment-gnulinux.so.2.2.0, not found (try using
> -rpath or -rpath-link)

>
> Perhaps it lacks a LINK_LIBRARY_PATH ?

Probably something like that... however, it is advised to link with the full
path library (/target/usr/bin/libfoo.so) instead of -lfoo. I believe we do
this everywhere, because we use the find_library() cmake function. The linker
suggests to use an rpath, but rpaths must be set to the run-time paths (ie as
they appear when executing the code on the target). I need more output, with
make VERBOSE=1 to diagnose this.

>
>
> I'am not sure that those patches are the best solution. So give me your
> opinion please.
>
>
> Paul.

Peter

OCL cross compil problem and RTT compil warning

Submitted by Polch on Tue, 2010-12-14 15:52.

Hi.

When i compile RTT 2.2.0 i have this warning :

Quote:

sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp: In static member function 'static RTT::base::ChannelElementBase::shared_ptr RTT::internal::ConnFactory::createRemoteConnection(RTT::base::OutputPortInterface&, RTT::base::InputPortInterface&, const RTT::ConnPolicy&)':
sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp:83:16: warning: converting 'false' to pointer type for argument 1 of 'boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T = RTT::base::ChannelElementBase]'
sources/orocos-rtt-2.2.0/rtt/internal/ConnFactory.cpp:89:16: warning: converting 'false' to pointer type for argument 1 of 'boost::intrusive_ptr<T>::intrusive_ptr(T*, bool) [with T = RTT::base::ChannelElementBase]'

When i compile OCL 2.2.0 i have these error (it's a cross compilation case see below) :

Quote:

-- Optional library RTT_PLUGIN_rtt-scripting NOT FOUND. If the library is already installed, use the RTT_PLUGIN_rtt-scripting_ROOT_DIR environment variable or ccmake to set the missing variables manually.
-- Optional library RTT_PLUGIN_rtt-marshalling NOT FOUND. If the library is already installed, use the RTT_PLUGIN_rtt-marshalling_ROOT_DIR environment variable or ccmake to set the missing variables manually.

and later

Quote:

TaskBrowser.cpp:(.text+0x4a22): undefined reference to `RTT::scripting::Parser::Parser(RTT::TaskContext*)'
...

Would it be possible to compile without manually defining RTT_PLUGIN_rtt-scripting_ROOT_DIR ?
As i cross compile i use a CMAKE_INSTALL_PREFIX that refer to a target path and an OROCOS_INSTALL that refer to an host path. Is there any mistake ?

Thank for your help.

Paul.

Orocos Real-Time Toolkit

OCL Home

OCL Download

OCL Documentation

OCL cross compil problem and RTT compil warning

OCL cross compil problem and RTT compil warning

Hello.I have found the

Hello.I have found the

Hello.I have found the

OCL cross compil problem and RTT compil warning

OCL cross compil problem and RTT compil warning

OCL cross compil problem and RTT compil warning

OCL cross compil problem and RTT compil warning

Hello.I have found the

OCL cross compil problem and RTT compil warning