first experience with 2.0

Submitted by Sagar on Tue, 2010-09-21 15:44

Orocos-users

Hello,

Sometime ago I asked on this list whether to use Orocos-1.x or 2.0 for
my new project, and based on the responses I decided to use 1.10. I
downloaded, cross-compiled, installed 1.10 and everything works. Today,
had some spare time and decided to look at 2.0.

I couldn't get it working. Here is what I did.

[Orocos will be used on a freescale MP5200b processor with ELDK. I do
_not_ want to install it for my laptop's native Ubuntu 10.04 amd64
environment.]

1. wget -c
http://www.orocos.org/stable/toolchain/v2.0.1/orocos-toolchain-2.0.1-src...
2. tar jxvf orocos-toolchain-2.0.1-src.tar.bz2
3. cd orocos-toolchain-2.0.1
4. ./bootstrap_toolchain

I told it to ask me before installing new packages. When it wanted to
install libxml2 and so on, I told it "no" and the script aborted. (I
don't want to install these orocos dependencies on my native system.

5. orocos-toolchain-2.0.1/README.txt mentions "See the
autoproj/README.txt file to customize build and install options."
However, the directory autoproj/ has no file called README.txt (or any
readme type file)

6. Figuring that I'm on my own, I did: cd rtt;mkdir build;cd build;
7. export CMAKE_INCLUDE_PATH=/the/proper/paths;export
CMAKE_LIBRARY_PATH=/the/proper/paths
8. CC=ppc_6xx-gcc CXX=ppc_6xx-g++ LD=ppc_6xx-ld ccmake -i ..
-DCROSS_COMPILE=ppc_6xx-

This step found all dependencies, there were no errors. after
configuring and generating I typed

9. make

At this point, I got a bunch of errors because it couldn't find the
boost headers (why?)

<sni

Scanning dependencies of target orocos-rtt-gnulinux_dynamic
[ 1%] Building CXX object
rtt/CMakeFiles/orocos-rtt-gnulinux_dynamic.dir/Handle.cpp.o
In file included from
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/Handle.hpp:42,
from
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/Handle.cpp:39:
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/internal/SignalBase.hpp:42:35:
error: boost/intrusive_ptr.hpp: No such file or directory
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/internal/SignalBase.hpp:43:30:
error: boost/function.hpp: No such file or directory
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/internal/SignalBase.hpp:56:32:
error: boost/shared_ptr.hpp: No such file or directory
...
...
<sni

10. To make sure my environment variables were correct, I did:
cd /path/to/orocos-rtt-1.10.4/build/;rm -rf *;
11. The same cmake command as above i.e.
CC=ppc_6xx-gcc CXX=ppc_6xx-g++ LD=ppc_6xx-ld ccmake -i ..
-DCROSS_COMPILE=ppc_6xx-
12. After configuring and generating I typed make and everything built
properly.

13. I manually verified the presence of the headers that rtt considered
missing. They are there.

So what am I missing?

Regards,
Sagar

first experience with 2.0

Submitted by peter on Tue, 2010-09-21 19:32.

On Tuesday 21 September 2010 17:40:29 Sagar Behere wrote:
> Hello,
>
> Sometime ago I asked on this list whether to use Orocos-1.x or 2.0 for
> my new project, and based on the responses I decided to use 1.10. I
> downloaded, cross-compiled, installed 1.10 and everything works. Today,
> had some spare time and decided to look at 2.0.
>
> I couldn't get it working. Here is what I did.
>
> [Orocos will be used on a freescale MP5200b processor with ELDK. I do
> _not_ want to install it for my laptop's native Ubuntu 10.04 amd64
> environment.]
>
> 1. wget -c
> http://www.orocos.org/stable/toolchain/v2.0.1/orocos-toolchain-2.0.1-src.ta
> r.bz2 2. tar jxvf orocos-toolchain-2.0.1-src.tar.bz2
> 3. cd orocos-toolchain-2.0.1
> 4. ./bootstrap_toolchain
>
> I told it to ask me before installing new packages. When it wanted to
> install libxml2 and so on, I told it "no" and the script aborted. (I
> don't want to install these orocos dependencies on my native system.

In that case, you can edit the file autoproj/config.yml and set this line:

automatic_osdeps: false

autoproj then will always assume everything is fine.

>
> 5. orocos-toolchain-2.0.1/README.txt mentions "See the
> autoproj/README.txt file to customize build and install options."
> However, the directory autoproj/ has no file called README.txt (or any
> readme type file)

That's a packaging bug. You can also look at it here:
http://gitorious.org/orocos-toolchain/build/blobs/master/README.txt

>
> 6. Figuring that I'm on my own, I did: cd rtt;mkdir build;cd build;
> 7. export CMAKE_INCLUDE_PATH=/the/proper/paths;export
> CMAKE_LIBRARY_PATH=/the/proper/paths

It is prefered to write CMAKE_PREFIX_PATH=/the/proper/paths
then you can omit the include/library combo, which is a lot of duplication.

> 8. CC=ppc_6xx-gcc CXX=ppc_6xx-g++ LD=ppc_6xx-ld ccmake -i ..
> -DCROSS_COMPILE=ppc_6xx-

When you're cross compiling, it is best to create a 'toolchain file', as
described here :
http://www.paraview.org/Wiki/CMake_Cross_Compiling#The_toolchain_file

You can copy the orocos-rtt.default.cmake to orocos-rtt.cmake and edit that
file in order to make it a toolchain file. It will be automatically loaded by
our cmake scripts. Then you also no longer need the exports, as they are in
that file.

>
> This step found all dependencies, there were no errors. after
> configuring and generating I typed
>
> 9. make
>
> At this point, I got a bunch of errors because it couldn't find the
> boost headers (why?)

That's 'interesting'... I know quite a number of people use boost in non-
standard locations. It's possible that a cleanup before the release removed
the line 'include_directories( ${Boost_INCLUDE_DIR} )'. You could add it in
config/check_depend.cmake after Boost_FOUND was detected...

>
> <sni

> Scanning dependencies of target orocos-rtt-gnulinux_dynamic
> [ 1%] Building CXX object
> rtt/CMakeFiles/orocos-rtt-gnulinux_dynamic.dir/Handle.cpp.o
> In file included from
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/Handle.hpp:42,
> from
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/Handle.cpp:39:
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/internal/SignalBase.hp
> p:42:35: error: boost/intrusive_ptr.hpp: No such file or directory
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/internal/SignalBase.hp
> p:43:30: error: boost/function.hpp: No such file or directory
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/internal/SignalBase.hp
> p:56:32: error: boost/shared_ptr.hpp: No such file or directory
> ...
> ...
> <sni

>
> 10. To make sure my environment variables were correct, I did:
> cd /path/to/orocos-rtt-1.10.4/build/;rm -rf *;
> 11. The same cmake command as above i.e.
> CC=ppc_6xx-gcc CXX=ppc_6xx-g++ LD=ppc_6xx-ld ccmake -i ..
> -DCROSS_COMPILE=ppc_6xx-
> 12. After configuring and generating I typed make and everything built
> properly.

So 1.10 indeed works.

>
> 13. I manually verified the presence of the headers that rtt considered
> missing. They are there.
>
> So what am I missing?

It's probably the missing include_directories statement...

Peter

first experience with 2.0

Submitted by peter on Tue, 2010-09-21 19:40.

On Tuesday 21 September 2010 21:28:19 Peter Soetens wrote:
> On Tuesday 21 September 2010 17:40:29 Sagar Behere wrote:
> > Hello,
> >
> > Sometime ago I asked on this list whether to use Orocos-1.x or 2.0 for
> > my new project, and based on the responses I decided to use 1.10. I
> > downloaded, cross-compiled, installed 1.10 and everything works. Today,
> > had some spare time and decided to look at 2.0.
> >
> > I couldn't get it working. Here is what I did.
> >
> > [Orocos will be used on a freescale MP5200b processor with ELDK. I do
> > _not_ want to install it for my laptop's native Ubuntu 10.04 amd64
> > environment.]
> >
> > 1. wget -c
> > http://www.orocos.org/stable/toolchain/v2.0.1/orocos-toolchain-2.0.1-src.
> > ta r.bz2 2. tar jxvf orocos-toolchain-2.0.1-src.tar.bz2
> > 3. cd orocos-toolchain-2.0.1
> > 4. ./bootstrap_toolchain
> >
> > I told it to ask me before installing new packages. When it wanted to
> > install libxml2 and so on, I told it "no" and the script aborted. (I
> > don't want to install these orocos dependencies on my native system.
>
> In that case, you can edit the file autoproj/config.yml and set this line:
>
> automatic_osdeps: false
>
> autoproj then will always assume everything is fine.
>
> > 5. orocos-toolchain-2.0.1/README.txt mentions "See the
> > autoproj/README.txt file to customize build and install options."
> > However, the directory autoproj/ has no file called README.txt (or any
> > readme type file)
>
> That's a packaging bug. You can also look at it here:
> http://gitorious.org/orocos-toolchain/build/blobs/master/README.txt
>
> > 6. Figuring that I'm on my own, I did: cd rtt;mkdir build;cd build;
> > 7. export CMAKE_INCLUDE_PATH=/the/proper/paths;export
> > CMAKE_LIBRARY_PATH=/the/proper/paths
>
> It is prefered to write CMAKE_PREFIX_PATH=/the/proper/paths
> then you can omit the include/library combo, which is a lot of duplication.
>
> > 8. CC=ppc_6xx-gcc CXX=ppc_6xx-g++ LD=ppc_6xx-ld ccmake -i ..
> > -DCROSS_COMPILE=ppc_6xx-
>
> When you're cross compiling, it is best to create a 'toolchain file', as
> described here :
> http://www.paraview.org/Wiki/CMake_Cross_Compiling#The_toolchain_file
>
> You can copy the orocos-rtt.default.cmake to orocos-rtt.cmake and edit that
> file in order to make it a toolchain file. It will be automatically loaded
> by our cmake scripts. Then you also no longer need the exports, as they
> are in that file.
>
> > This step found all dependencies, there were no errors. after
> > configuring and generating I typed
> >
> > 9. make
> >
> > At this point, I got a bunch of errors because it couldn't find the
> > boost headers (why?)
>
> That's 'interesting'... I know quite a number of people use boost in non-
> standard locations. It's possible that a cleanup before the release removed
> the line 'include_directories( ${Boost_INCLUDE_DIR} )'. You could add it in
> config/check_depend.cmake after Boost_FOUND was detected...

Ignore that. It *is* there, on line 254 of check_depend.cmake, adding all
found include directories at once.

You could try to change the var ${Boost_INCLUDE_DIR} to ${Boost_INCLUDE_DIRS}
in that file and see what happens. Both should work though. The Boost detection
magic in 1.10 and 2.0 is the same, except that we require Boost 1.38 in 2.0
and 1.33 in 1.10.

Beats me.

Peter

first experience with 2.0

Submitted by Sagar on Wed, 2010-09-22 14:48.

Hello Peter,

Executive summary: 1. Boost_FOUND is not set to TRUE even though Boost
is found. 2. ENABLE_MQ set to ON causes build to fail. 3. OCL build
fails due to some missing lib which needs to be linked?

Read on for the gory details.

rtt-2.0 (cross-)compilation finds the boost stuff now after a really
weird hack. [But rtt still doesn't compile due to a new error.]

I tried everything you said, but it still did not work. However, when I
accidentally tried compiling in a terminal where the
CMAKE_INCLUDE_/CMAKE_LIBRARY_/CMAKE_PREFIX_ paths were not set, I got
the following output:

---
CMake Error at /usr/share/cmake-2.8/Modules/FindBoost.cmake:894 (message):
Unable to find the requested Boost libraries.

Boost version: 1.44.0

Boost include path: /opt/boost_1_44_0

The following Boost libraries could not be found:

boost_serialization

No Boost libraries were found. You may need to set Boost_LIBRARYDIR
to the
directory containing Boost libraries or BOOST_ROOT to the location of
Boost.
---

This is weird because the first line says that the boost library was NOT
found, and the next lines say that it WAS found.

Then I fixed the CMAKE_INCLUDE_PATH variable to the right value and all
errors disappeared. Toggling the advanced view of ccmake, I saw the
following variables:
-----
Boost_FILESYSTEM_LIBRARY */opt/build/lib/libboost_filesystem.a

Boost_FILESYSTEM_LIBRARY_DEBUG
*Boost_FILESYSTEM_LIBRARY_DEBUG-NOTFOUND

Boost_FILESYSTEM_LIBRARY_RELEA */opt/build/lib/libboost_filesystem.a

Boost_INCLUDE_DIR */opt/build/include

Boost_LIBRARY_DIRS */opt/build/lib

Boost_SERIALIZATION_LIBRARY
*/opt/build/lib/libboost_serialization.a

Boost_SERIALIZATION_LIBRARY_DE
*Boost_SERIALIZATION_LIBRARY_DEBUG-NOTFOUND

Boost_SERIALIZATION_LIBRARY_RE
*/opt/build/lib/libboost_serialization.a

Boost_SYSTEM_LIBRARY */opt/build/lib/libboost_system.a

Boost_SYSTEM_LIBRARY_DEBUG *Boost_SYSTEM_LIBRARY_DEBUG-NOTFOUND

Boost_SYSTEM_LIBRARY_RELEASE */opt/build/lib/libboost_system.a

Boost_THREAD_LIBRARY_DEBUG *Boost_THREAD_LIBRARY_DEBUG-NOTFOUND

Boost_THREAD_LIBRARY_RELEASE *Boost_THREAD_LIBRARY_RELEASE-NOTFOUND

Boost_UNIT_TEST_FRAMEWORK_LIBR
*/opt/build/lib/libboost_unit_test_framework.a

Boost_UNIT_TEST_FRAMEWORK_LIBR
*Boost_UNIT_TEST_FRAMEWORK_LIBRARY_DEBUG-NOTFOUND

Boost_UNIT_TEST_FRAMEWORK_LIBR
*/opt/build/lib/libboost_unit_test_framework.a
---------

So all the paths ARE correct!! but when I typed make, it still did not
work because it couldn't find the boost headers.

So I went to config/check_depend.cmake and on a hunch, added

if (NOT Boost_FOUND)
list(APPEND OROCOS-RTT_INCLUDE_DIRS ${Boost_INCLUDE_DIR} )
endif()

because it seemed like everything was there but maybe Boost_FOUND was
not being set to true.

That worked !?

So the cross compile progressed till 41% then stopped with
----------
[ 41%] Building CXX object
rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.dir/MQLib.cpp.o
In file included from
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/MQSerializationProtocol.hpp:50,
from
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/MQLib.cpp:42:
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/binary_data_archive.hpp:
In member function 'void
RTT::mqueue::binary_data_iarchive::load_binary(void*, size_t)':
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/binary_data_archive.hpp:245:
error: 'stream_error' is not a member of 'boost::archive::archive_exception'
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/binary_data_archive.hpp:259:
error: 'stream_error' is not a member of 'boost::archive::archive_exception'
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/binary_data_archive.hpp:
In member function 'void
RTT::mqueue::binary_data_oarchive::save_binary(const void*, size_t)':
/home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/binary_data_archive.hpp:434:
error: 'stream_error' is not a member of 'boost::archive::archive_exception'
make[2]: ***
[rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.dir/MQLib.cpp.o]
Error 1
make[1]: ***
[rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.dir/all]
Error 2
make: *** [all] Error 2
-----------

So I went back to ccmake and set ENABLE_MQ to OFF. But it still stopped
compiling with the same error. I did rm -rf * in the build directory and
repeated the process, setting ENABLE_MQ to OFF. Again the same error and
on running ccmake, I discovered that ENABLE_MQ was set to ON again ?! It
CANNOT be turned OFF for some reason. If I set it to OFF and then hit
'c' to configure ccmake again, it is automagically set back to ON. This
was true of all other ON/OFF variables whose values were toggled. This
was because I followed your suggestion of using orocos-rtt.cmake, where
I put

SET(CMAKE_C_COMPILER /opt/eldk/usr/bin/ppc-linux-gcc)
SET(CMAKE_CXX_COMPILER /opt/eldk/usr/bin/ppc-linux-g++)

that would cause the cache to be reloaded all the time because
CMAKE_CXX_COMPILER value had changed.

So I deleted orocos-rtt.cmake and went back to cross compiling with

CC=ppc_6xx-gcc CXX=ppc_6xx-g++ LD=ppc_6xx-ld ccmake -i ..

This time, I set ENABLE_MQ to OFF and then the build completed.

When cross-compiling ocl, at some point the build fails with:
--------
Linking CXX executable helloworld
/opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
`tgetnum'
/opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
`tgetent'
/opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
`tgetstr'
/opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
`tgoto'
/opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to `UP'
/opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to `BC'
/opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
`tputs'
/opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to `PC'
/opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
`tgetflag'
collect2: ld returned 1 exit status
make[2]: *** [helloworld/helloworld] Error 1
make[1]: *** [helloworld/CMakeFiles/helloworld.dir/all] Error 2
make: *** [all] Error 2
---------

I realize that this is an ELDK issue, don't realize why ocl-1.10
compiled without issues with the same libreadline.

Googling around seems to suggest that I need to link with the ncurses
library (which is not found by ccmake since it is not there, but that
was never a problem with 1.10).

So I'll try to see if it works once I install the libncurses and then
get back to you.

Regards,
Sagar

On 09/21/2010 09:38 PM, Peter Soetens wrote:
> On Tuesday 21 September 2010 21:28:19 Peter Soetens wrote:
>> On Tuesday 21 September 2010 17:40:29 Sagar Behere wrote:
>>> Hello,
>>>
>>> Sometime ago I asked on this list whether to use Orocos-1.x or 2.0 for
>>> my new project, and based on the responses I decided to use 1.10. I
>>> downloaded, cross-compiled, installed 1.10 and everything works. Today,
>>> had some spare time and decided to look at 2.0.
>>>
>>> I couldn't get it working. Here is what I did.
>>>
>>> [Orocos will be used on a freescale MP5200b processor with ELDK. I do
>>> _not_ want to install it for my laptop's native Ubuntu 10.04 amd64
>>> environment.]
>>>
>>> 1. wget -c
>>> http://www.orocos.org/stable/toolchain/v2.0.1/orocos-toolchain-2.0.1-src.
>>> ta r.bz2 2. tar jxvf orocos-toolchain-2.0.1-src.tar.bz2
>>> 3. cd orocos-toolchain-2.0.1
>>> 4. ./bootstrap_toolchain
>>>
>>> I told it to ask me before installing new packages. When it wanted to
>>> install libxml2 and so on, I told it "no" and the script aborted. (I
>>> don't want to install these orocos dependencies on my native system.
>>
>> In that case, you can edit the file autoproj/config.yml and set this line:
>>
>> automatic_osdeps: false
>>
>> autoproj then will always assume everything is fine.
>>
>>> 5. orocos-toolchain-2.0.1/README.txt mentions "See the
>>> autoproj/README.txt file to customize build and install options."
>>> However, the directory autoproj/ has no file called README.txt (or any
>>> readme type file)
>>
>> That's a packaging bug. You can also look at it here:
>> http://gitorious.org/orocos-toolchain/build/blobs/master/README.txt
>>
>>> 6. Figuring that I'm on my own, I did: cd rtt;mkdir build;cd build;
>>> 7. export CMAKE_INCLUDE_PATH=/the/proper/paths;export
>>> CMAKE_LIBRARY_PATH=/the/proper/paths
>>
>> It is prefered to write CMAKE_PREFIX_PATH=/the/proper/paths
>> then you can omit the include/library combo, which is a lot of duplication.
>>
>>> 8. CC=ppc_6xx-gcc CXX=ppc_6xx-g++ LD=ppc_6xx-ld ccmake -i ..
>>> -DCROSS_COMPILE=ppc_6xx-
>>
>> When you're cross compiling, it is best to create a 'toolchain file', as
>> described here :
>> http://www.paraview.org/Wiki/CMake_Cross_Compiling#The_toolchain_file
>>
>> You can copy the orocos-rtt.default.cmake to orocos-rtt.cmake and edit that
>> file in order to make it a toolchain file. It will be automatically loaded
>> by our cmake scripts. Then you also no longer need the exports, as they
>> are in that file.
>>
>>> This step found all dependencies, there were no errors. after
>>> configuring and generating I typed
>>>
>>> 9. make
>>>
>>> At this point, I got a bunch of errors because it couldn't find the
>>> boost headers (why?)
>>
>> That's 'interesting'... I know quite a number of people use boost in non-
>> standard locations. It's possible that a cleanup before the release removed
>> the line 'include_directories( ${Boost_INCLUDE_DIR} )'. You could add it in
>> config/check_depend.cmake after Boost_FOUND was detected...
>
> Ignore that. It *is* there, on line 254 of check_depend.cmake, adding all
> found include directories at once.
>
> You could try to change the var ${Boost_INCLUDE_DIR} to ${Boost_INCLUDE_DIRS}
> in that file and see what happens. Both should work though. The Boost detection
> magic in 1.10 and 2.0 is the same, except that we require Boost 1.38 in 2.0
> and 1.33 in 1.10.
>
> Beats me.
>
> Peter

first experience with 2.0

Submitted by peter on Thu, 2010-09-23 10:52.

On Wednesday 22 September 2010 16:43:48 Sagar Behere wrote:
> Hello Peter,
>
> Executive summary: 1. Boost_FOUND is not set to TRUE even though Boost
> is found. 2. ENABLE_MQ set to ON causes build to fail. 3. OCL build
> fails due to some missing lib which needs to be linked?
>
> Read on for the gory details.
>
> rtt-2.0 (cross-)compilation finds the boost stuff now after a really
> weird hack. [But rtt still doesn't compile due to a new error.]
>
> I tried everything you said, but it still did not work. However, when I
> accidentally tried compiling in a terminal where the
> CMAKE_INCLUDE_/CMAKE_LIBRARY_/CMAKE_PREFIX_ paths were not set, I got
> the following output:
>
> ---
> CMake Error at /usr/share/cmake-2.8/Modules/FindBoost.cmake:894 (message):
> Unable to find the requested Boost libraries.
>
> Boost version: 1.44.0
>
> Boost include path: /opt/boost_1_44_0
>
> The following Boost libraries could not be found:
>
> boost_serialization
>
> No Boost libraries were found. You may need to set Boost_LIBRARYDIR
> to the
> directory containing Boost libraries or BOOST_ROOT to the location of
> Boost.
> ---
>
> This is weird because the first line says that the boost library was NOT
> found, and the next lines say that it WAS found.

No it doesn't. Re-read it :-). What *is* wrong here is that we invoke the
find_package(Boost) macro a second time in the mqueue code, which is not
allowed (the Boost macro handles it very badly). It should just check for
serialization, and disable it if not found.

>
> Then I fixed the CMAKE_INCLUDE_PATH variable to the right value and all
> errors disappeared. Toggling the advanced view of ccmake, I saw the
> following variables:
> -----
> Boost_FILESYSTEM_LIBRARY */opt/build/lib/libboost_filesystem.a
>
>
> Boost_FILESYSTEM_LIBRARY_DEBUG
> *Boost_FILESYSTEM_LIBRARY_DEBUG-NOTFOUND
>
> Boost_FILESYSTEM_LIBRARY_RELEA */opt/build/lib/libboost_filesystem.a
>
>
> Boost_INCLUDE_DIR */opt/build/include
>
>
> Boost_LIBRARY_DIRS */opt/build/lib
>
>
> Boost_SERIALIZATION_LIBRARY
> */opt/build/lib/libboost_serialization.a
>
> Boost_SERIALIZATION_LIBRARY_DE
> *Boost_SERIALIZATION_LIBRARY_DEBUG-NOTFOUND
>
> Boost_SERIALIZATION_LIBRARY_RE
> */opt/build/lib/libboost_serialization.a
>
> Boost_SYSTEM_LIBRARY */opt/build/lib/libboost_system.a
>
>
> Boost_SYSTEM_LIBRARY_DEBUG *Boost_SYSTEM_LIBRARY_DEBUG-NOTFOUND
>
>
> Boost_SYSTEM_LIBRARY_RELEASE */opt/build/lib/libboost_system.a
>
>
> Boost_THREAD_LIBRARY_DEBUG *Boost_THREAD_LIBRARY_DEBUG-NOTFOUND
>
>
> Boost_THREAD_LIBRARY_RELEASE *Boost_THREAD_LIBRARY_RELEASE-NOTFOUND
>
>
> Boost_UNIT_TEST_FRAMEWORK_LIBR
> */opt/build/lib/libboost_unit_test_framework.a
>
> Boost_UNIT_TEST_FRAMEWORK_LIBR
> *Boost_UNIT_TEST_FRAMEWORK_LIBRARY_DEBUG-NOTFOUND
>
> Boost_UNIT_TEST_FRAMEWORK_LIBR
> */opt/build/lib/libboost_unit_test_framework.a
> ---------
>
> So all the paths ARE correct!! but when I typed make, it still did not
> work because it couldn't find the boost headers.
>
> So I went to config/check_depend.cmake and on a hunch, added
>
> if (NOT Boost_FOUND)
> list(APPEND OROCOS-RTT_INCLUDE_DIRS ${Boost_INCLUDE_DIR} )
> endif()
>
> because it seemed like everything was there but maybe Boost_FOUND was
> not being set to true.
>
> That worked !?

Well, I think you found the culprit, that is, that Boost_FOUND is not set to
true. The reason is this:

# Boost_FOUND System has Boost, this means the include dir was
# found, as well as all the libraries specified in
# the COMPONENTS list.

So you had a missing component, and this flag was never set. The real fix is to
replace Boost_FOUND with Boost_INCLUDE_DIR.

>
> So the cross compile progressed till 41% then stopped with
> ----------
> [ 41%] Building CXX object
> rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.dir/M
> QLib.cpp.o In file included from
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/MQSe
> rializationProtocol.hpp:50, from
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/MQLi
> b.cpp:42:
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/bin
> ary_data_archive.hpp: In member function 'void
> RTT::mqueue::binary_data_iarchive::load_binary(void*, size_t)':
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/bina
> ry_data_archive.hpp:245: error: 'stream_error' is not a member of
> 'boost::archive::archive_exception'
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/bin
> ary_data_archive.hpp:259: error: 'stream_error' is not a member of
> 'boost::archive::archive_exception'
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/bin
> ary_data_archive.hpp: In member function 'void
> RTT::mqueue::binary_data_oarchive::save_binary(const void*, size_t)':
> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/bina
> ry_data_archive.hpp:434: error: 'stream_error' is not a member of
> 'boost::archive::archive_exception' make[2]: ***
> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.dir/
> MQLib.cpp.o] Error 1
> make[1]: ***
> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.dir/
> all] Error 2
> make: *** [all] Error 2
> -----------
>
> So I went back to ccmake and set ENABLE_MQ to OFF. But it still stopped
> compiling with the same error. I did rm -rf * in the build directory and
> repeated the process, setting ENABLE_MQ to OFF. Again the same error and
> on running ccmake, I discovered that ENABLE_MQ was set to ON again ?! It
> CANNOT be turned OFF for some reason. If I set it to OFF and then hit
> 'c' to configure ccmake again, it is automagically set back to ON. This
> was true of all other ON/OFF variables whose values were toggled. This
> was because I followed your suggestion of using orocos-rtt.cmake, where
> I put
>
> SET(CMAKE_C_COMPILER /opt/eldk/usr/bin/ppc-linux-gcc)
> SET(CMAKE_CXX_COMPILER /opt/eldk/usr/bin/ppc-linux-g++)
>
> that would cause the cache to be reloaded all the time because
> CMAKE_CXX_COMPILER value had changed.

OMG ! I didn't know that. This is disastrous ! So we need to add a big fat
warning in the orocos-rtt.default.cmake file then !

>
> So I deleted orocos-rtt.cmake and went back to cross compiling with
>
> CC=ppc_6xx-gcc CXX=ppc_6xx-g++ LD=ppc_6xx-ld ccmake -i ..
>
> This time, I set ENABLE_MQ to OFF and then the build completed.

Thanks for doing the work, I'll release 2.0.2 asap with all these fixes in it.

>
> When cross-compiling ocl, at some point the build fails with:
> --------
> Linking CXX executable helloworld
> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> `tgetnum'
> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> `tgetent'
> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> `tgetstr'
> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> `tgoto'
> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> `UP' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference
> to `BC' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined
> reference to `tputs'
> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> `PC' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference
> to `tgetflag'
> collect2: ld returned 1 exit status
> make[2]: *** [helloworld/helloworld] Error 1
> make[1]: *** [helloworld/CMakeFiles/helloworld.dir/all] Error 2
> make: *** [all] Error 2
> ---------
>
> I realize that this is an ELDK issue, don't realize why ocl-1.10
> compiled without issues with the same libreadline.
>
> Googling around seems to suggest that I need to link with the ncurses
> library (which is not found by ccmake since it is not there, but that
> was never a problem with 1.10).
>
> So I'll try to see if it works once I install the libncurses and then
> get back to you.

It's the eternal battle between readline +- ncurses. Sometimes it depends on
it sometimes not, and it probably depends on the platform and also the
static/dynamic linking. We never got it right. 1.10 links with ncurses, 2.0
doesn't. I'll add a switch that on the Linux platform, we also link with
ncurses. It probably linked with your host's ncurses during the 1.10 build ?

Peter

first experience with 2.0

Submitted by Sagar on Thu, 2010-09-23 13:20.

On 09/23/2010 11:52 AM, Peter Soetens wrote:

>> So the cross compile progressed till 41% then stopped with
>> ----------
>> [ 41%] Building CXX object
>> rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.dir/M
>> QLib.cpp.o In file included from
>> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/MQSe
>> rializationProtocol.hpp:50, from
>> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/MQLi
>> b.cpp:42:
>> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/bin
>> ary_data_archive.hpp: In member function 'void
>> RTT::mqueue::binary_data_iarchive::load_binary(void*, size_t)':
>> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/bina
>> ry_data_archive.hpp:245: error: 'stream_error' is not a member of
>> 'boost::archive::archive_exception'
>> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/bin
>> ary_data_archive.hpp:259: error: 'stream_error' is not a member of
>> 'boost::archive::archive_exception'
>> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/bin
>> ary_data_archive.hpp: In member function 'void
>> RTT::mqueue::binary_data_oarchive::save_binary(const void*, size_t)':
>> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/bina
>> ry_data_archive.hpp:434: error: 'stream_error' is not a member of
>> 'boost::archive::archive_exception' make[2]: ***
>> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.dir/
>> MQLib.cpp.o] Error 1
>> make[1]: ***
>> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.dir/
>> all] Error 2
>> make: *** [all] Error 2

Do you know why the build fails here? Is it because of boost_1.44 which
is different from the recommended 1.38? Setting ENABLE_MQ to OFF is okay
for now because I don't see us communicating in real-time to other
processes. But it'd be good to know that it is there, in case we need it.

>> When cross-compiling ocl, at some point the build fails with:
>> --------
>> Linking CXX executable helloworld
>> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> `tgetnum'
>> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> `tgetent'
>> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> `tgetstr'
>> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> `tgoto'
>> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> `UP' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference
>> to `BC' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined
>> reference to `tputs'
>> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> `PC' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference
>> to `tgetflag'
>> collect2: ld returned 1 exit status
>> make[2]: *** [helloworld/helloworld] Error 1
>> make[1]: *** [helloworld/CMakeFiles/helloworld.dir/all] Error 2
>> make: *** [all] Error 2
>> ---------
> It's the eternal battle between readline +- ncurses. Sometimes it depends on
> it sometimes not, and it probably depends on the platform and also the
> static/dynamic linking. We never got it right. 1.10 links with ncurses, 2.0
> doesn't. I'll add a switch that on the Linux platform, we also link with
> ncurses. It probably linked with your host's ncurses during the 1.10 build ?

I checked everything again and the standard ELDK install does contain
the ncurses library. During ccmake, all the libraries are detected. I
can see the messages

-- Looking for libncurses - found
-- Looking for readline/readline.h - found
-- Looking for Boost Ublas - found

toggling the advanced options shows the following values are correctly set

CURSES_CURSES_H_PATH */opt/eldk/ppc_6xx/usr/include

CURSES_CURSES_LIBRARY
*/opt/eldk/ppc_6xx/usr/lib/libcurses.so

CURSES_EXTRA_LIBRARY *CURSES_EXTRA_LIBRARY-NOTFOUND

CURSES_FORM_LIBRARY */opt/eldk/ppc_6xx/usr/lib/libform.so

CURSES_HAVE_CURSES_H
*/opt/eldk/ppc_6xx/usr/include/curses.h

CURSES_INCLUDE_PATH */opt/eldk/ppc_6xx/usr/include

CURSES_LIBRARY
*/opt/eldk/ppc_6xx/usr/lib/libcurses.so

CURSES_NCURSES_LIBRARY
*/opt/eldk/ppc_6xx/usr/lib/libncurses.so

However, I still get the previous error messages (undefined references)
from libreadline.so.

If I edit ocl/helloworld/CMakeLists.txt and append ncurses to the
TARGET_LINK_LIBRARIES so that the line reads

TARGET_LINK_LIBRARIES( helloworld ${OROCOS_RTT_LIBS} ncurses)

Then helloworld compiles and links properly. After that the
deployer-gnulinux linking fails and then I need to go to the
ocl/bin/CMakeLists.txt file and add ncurses to the TARGET_LINK_LIBRARIES
() there and then it links as well and the complete build is done properly.

So there needs to be a way to say: Libreadline needs libncurses and when
both are found, then link with readline and ncurses.

I don't know enough about cmake/orocos-build system to know where and
how this should be done.

Regards,
Sagar

first experience with 2.0

Submitted by peter on Thu, 2010-09-23 14:00.

On Thursday 23 September 2010 15:16:21 Sagar Behere wrote:
> On 09/23/2010 11:52 AM, Peter Soetens wrote:
> >> So the cross compile progressed till 41% then stopped with
> >> ----------
> >> [ 41%] Building CXX object
> >> rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.di
> >> r/M QLib.cpp.o In file included from
> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/M
> >> QSe rializationProtocol.hpp:50, from
> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/M
> >> QLi b.cpp:42:
> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
> >> in ary_data_archive.hpp: In member function 'void
> >> RTT::mqueue::binary_data_iarchive::load_binary(void*, size_t)':
> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
> >> ina ry_data_archive.hpp:245: error: 'stream_error' is not a member of
> >> 'boost::archive::archive_exception'
> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
> >> in ary_data_archive.hpp:259: error: 'stream_error' is not a member of
> >> 'boost::archive::archive_exception'
> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
> >> in ary_data_archive.hpp: In member function 'void
> >> RTT::mqueue::binary_data_oarchive::save_binary(const void*, size_t)':
> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
> >> ina ry_data_archive.hpp:434: error: 'stream_error' is not a member of
> >> 'boost::archive::archive_exception' make[2]: ***
> >> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.d
> >> ir/ MQLib.cpp.o] Error 1
> >> make[1]: ***
> >> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.d
> >> ir/ all] Error 2
> >> make: *** [all] Error 2
>
> Do you know why the build fails here? Is it because of boost_1.44 which
> is different from the recommended 1.38? Setting ENABLE_MQ to OFF is okay
> for now because I don't see us communicating in real-time to other
> processes. But it'd be good to know that it is there, in case we need it.

Oh yes, I overlooked this. The 'serialization' API of Boost changes with every
Boost release, so we need to #ifdef this statement and provide alternative
code for boost 1.44+. Any Boost 1.44 user may submit a patch :-)

>
> >> When cross-compiling ocl, at some point the build fails with:
> >> --------
> >> Linking CXX executable helloworld
> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> >> `tgetnum'
> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> >> `tgetent'
> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> >> `tgetstr'
> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> >> `tgoto'
> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> >> `UP' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined
> >> reference to `BC' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so:
> >> undefined reference to `tputs'
> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
> >> `PC' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined
> >> reference to `tgetflag'
> >> collect2: ld returned 1 exit status
> >> make[2]: *** [helloworld/helloworld] Error 1
> >> make[1]: *** [helloworld/CMakeFiles/helloworld.dir/all] Error 2
> >> make: *** [all] Error 2
> >> ---------
> >
> > It's the eternal battle between readline +- ncurses. Sometimes it depends
> > on it sometimes not, and it probably depends on the platform and also
> > the static/dynamic linking. We never got it right. 1.10 links with
> > ncurses, 2.0 doesn't. I'll add a switch that on the Linux platform, we
> > also link with ncurses. It probably linked with your host's ncurses
> > during the 1.10 build ?
>
> I checked everything again and the standard ELDK install does contain
> the ncurses library. During ccmake, all the libraries are detected. I
> can see the messages
>
> -- Looking for libncurses - found
> -- Looking for readline/readline.h - found
> -- Looking for Boost Ublas - found

The cmake bug is in the linking of the orocos-taskbrowser library. I have
created a fix and pushed it to gitorious on the toolchain-2.0 branch.

See http://gitorious.org/orocos-
toolchain/ocl/commit/df892f530a90b4d8ed8d3bdc775ec509aab9e7c5

for the proposed fix.

Peter

first experience with 2.0

Submitted by Steven Bellens on Sat, 2010-11-06 09:32.

2010/9/23 Peter Soetens <peter [..] ...>:
> On Thursday 23 September 2010 15:16:21 Sagar Behere wrote:
>> On 09/23/2010 11:52 AM, Peter Soetens wrote:
>> >> So the cross compile progressed till 41% then stopped with
>> >> ----------
>> >> [ 41%] Building CXX object
>> >> rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.di
>> >> r/M QLib.cpp.o In file included from
>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/M
>> >> QSe rializationProtocol.hpp:50, from
>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/M
>> >> QLi b.cpp:42:
>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
>> >> in ary_data_archive.hpp: In member function 'void
>> >> RTT::mqueue::binary_data_iarchive::load_binary(void*, size_t)':
>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
>> >> ina ry_data_archive.hpp:245: error: 'stream_error' is not a member of
>> >> 'boost::archive::archive_exception'
>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
>> >> in ary_data_archive.hpp:259: error: 'stream_error' is not a member of
>> >> 'boost::archive::archive_exception'
>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
>> >> in ary_data_archive.hpp: In member function 'void
>> >> RTT::mqueue::binary_data_oarchive::save_binary(const void*, size_t)':
>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
>> >> ina ry_data_archive.hpp:434: error: 'stream_error' is not a member of
>> >> 'boost::archive::archive_exception' make[2]: ***
>> >> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.d
>> >> ir/ MQLib.cpp.o] Error 1
>> >> make[1]: ***
>> >> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.d
>> >> ir/ all] Error 2
>> >> make: *** [all] Error 2
>>
>> Do you know why the build fails here? Is it because of boost_1.44 which
>> is different from the recommended 1.38? Setting ENABLE_MQ to OFF is okay
>> for now because I don't see us communicating in real-time to other
>> processes. But it'd be good to know that it is there, in case we need it.
>
> Oh yes, I overlooked this. The 'serialization' API of Boost changes with every
> Boost release, so we need to #ifdef this statement and provide alternative
> code for boost 1.44+. Any Boost 1.44 user may submit a patch :-)

The API didn't change that much. The stream_error was split in an
input_stream_error and an output_stream_error.
Replacing all occurences by e.g. input_stream_error was enough for a
succesful compilation here. (using boost 1.44)

http://www.boost.org/doc/libs/1_44_0/libs/serialization/doc/index.html

I'm not that much of an RTT expert to know whether to change it to an
input or an output stream error, so I'll leave that up to you :)

regards,

Steven

>
>>
>> >> When cross-compiling ocl, at some point the build fails with:
>> >> --------
>> >> Linking CXX executable helloworld
>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> >> `tgetnum'
>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> >> `tgetent'
>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> >> `tgetstr'
>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> >> `tgoto'
>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> >> `UP' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined
>> >> reference to `BC' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so:
>> >> undefined reference to `tputs'
>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>> >> `PC' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined
>> >> reference to `tgetflag'
>> >> collect2: ld returned 1 exit status
>> >> make[2]: *** [helloworld/helloworld] Error 1
>> >> make[1]: *** [helloworld/CMakeFiles/helloworld.dir/all] Error 2
>> >> make: *** [all] Error 2
>> >> ---------
>> >
>> > It's the eternal battle between readline +- ncurses. Sometimes it depends
>> > on it sometimes not, and it probably depends on the platform and also
>> > the static/dynamic linking. We never got it right. 1.10 links with
>> > ncurses, 2.0 doesn't. I'll add a switch that on the Linux platform, we
>> > also link with ncurses. It probably linked with your host's ncurses
>> > during the 1.10 build ?
>>
>> I checked everything again and the standard ELDK install does contain
>> the ncurses library. During ccmake, all the libraries are detected. I
>> can see the messages
>>
>> -- Looking for libncurses - found
>> -- Looking for readline/readline.h - found
>> -- Looking for Boost Ublas - found
>
> The cmake bug is in the linking of the orocos-taskbrowser library. I have
> created a fix and pushed it to gitorious on the toolchain-2.0 branch.
>
> See http://gitorious.org/orocos-
> toolchain/ocl/commit/df892f530a90b4d8ed8d3bdc775ec509aab9e7c5
>
> for the proposed fix.
>
> Peter
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

first experience with 2.0

Submitted by Steven Bellens on Fri, 2010-12-17 10:40.

2010/11/4 Steven Bellens <steven [dot] bellens [..] ...>:
> 2010/9/23 Peter Soetens <peter [..] ...>:
>> On Thursday 23 September 2010 15:16:21 Sagar Behere wrote:
>>> On 09/23/2010 11:52 AM, Peter Soetens wrote:
>>> >> So the cross compile progressed till 41% then stopped with
>>> >> ----------
>>> >> [ 41%] Building CXX object
>>> >> rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.di
>>> >> r/M QLib.cpp.o In file included from
>>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/M
>>> >> QSe rializationProtocol.hpp:50, from
>>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/M
>>> >> QLi b.cpp:42:
>>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
>>> >> in ary_data_archive.hpp: In member function 'void
>>> >> RTT::mqueue::binary_data_iarchive::load_binary(void*, size_t)':
>>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
>>> >> ina ry_data_archive.hpp:245: error: 'stream_error' is not a member of
>>> >> 'boost::archive::archive_exception'
>>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
>>> >> in ary_data_archive.hpp:259: error: 'stream_error' is not a member of
>>> >> 'boost::archive::archive_exception'
>>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
>>> >> in ary_data_archive.hpp: In member function 'void
>>> >> RTT::mqueue::binary_data_oarchive::save_binary(const void*, size_t)':
>>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqueue/b
>>> >> ina ry_data_archive.hpp:434: error: 'stream_error' is not a member of
>>> >> 'boost::archive::archive_exception' make[2]: ***
>>> >> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.d
>>> >> ir/ MQLib.cpp.o] Error 1
>>> >> make[1]: ***
>>> >> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugin.d
>>> >> ir/ all] Error 2
>>> >> make: *** [all] Error 2
>>>
>>> Do you know why the build fails here? Is it because of boost_1.44 which
>>> is different from the recommended 1.38? Setting ENABLE_MQ to OFF is okay
>>> for now because I don't see us communicating in real-time to other
>>> processes. But it'd be good to know that it is there, in case we need it.
>>
>> Oh yes, I overlooked this. The 'serialization' API of Boost changes with every
>> Boost release, so we need to #ifdef this statement and provide alternative
>> code for boost 1.44+. Any Boost 1.44 user may submit a patch :-)
>
> The API didn't change that much. The stream_error was split in an
> input_stream_error and an output_stream_error.
> Replacing all occurences by e.g. input_stream_error was enough for a
> succesful compilation here. (using boost 1.44)
>
> http://www.boost.org/doc/libs/1_44_0/libs/serialization/doc/index.html
>
> I'm not that much of an RTT expert to know whether to change it to an
> input or an output stream error, so I'll leave that up to you :)

I tried to find the change in the boost API again but couldn't . patch
in appendix is tested with boost 1.44.

Steven

>
> regards,
>
> Steven
>
>>
>>>
>>> >> When cross-compiling ocl, at some point the build fails with:
>>> >> --------
>>> >> Linking CXX executable helloworld
>>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>>> >> `tgetnum'
>>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>>> >> `tgetent'
>>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>>> >> `tgetstr'
>>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>>> >> `tgoto'
>>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>>> >> `UP' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined
>>> >> reference to `BC' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so:
>>> >> undefined reference to `tputs'
>>> >> /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined reference to
>>> >> `PC' /opt/eldk/usr/../ppc_6xx/usr/lib/libreadline.so: undefined
>>> >> reference to `tgetflag'
>>> >> collect2: ld returned 1 exit status
>>> >> make[2]: *** [helloworld/helloworld] Error 1
>>> >> make[1]: *** [helloworld/CMakeFiles/helloworld.dir/all] Error 2
>>> >> make: *** [all] Error 2
>>> >> ---------
>>> >
>>> > It's the eternal battle between readline +- ncurses. Sometimes it depends
>>> > on it sometimes not, and it probably depends on the platform and also
>>> > the static/dynamic linking. We never got it right. 1.10 links with
>>> > ncurses, 2.0 doesn't. I'll add a switch that on the Linux platform, we
>>> > also link with ncurses. It probably linked with your host's ncurses
>>> > during the 1.10 build ?
>>>
>>> I checked everything again and the standard ELDK install does contain
>>> the ncurses library. During ccmake, all the libraries are detected. I
>>> can see the messages
>>>
>>> -- Looking for libncurses - found
>>> -- Looking for readline/readline.h - found
>>> -- Looking for Boost Ublas - found
>>
>> The cmake bug is in the linking of the orocos-taskbrowser library. I have
>> created a fix and pushed it to gitorious on the toolchain-2.0 branch.
>>
>> See http://gitorious.org/orocos-
>> toolchain/ocl/commit/df892f530a90b4d8ed8d3bdc775ec509aab9e7c5
>>
>> for the proposed fix.
>>
>> Peter
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>

first experience with 2.0

Submitted by Steven Bellens on Fri, 2010-12-17 10:40.

I tried to find the change in the boost API again but couldn't . patch
in appendix is tested with boost 1.44.

Steven

first experience with 2.0

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

On Friday 17 December 2010 11:37:28 Steven Bellens wrote:
> 2010/11/4 Steven Bellens <steven [dot] bellens [..] ...>:
> > 2010/9/23 Peter Soetens <peter [..] ...>:
> >> On Thursday 23 September 2010 15:16:21 Sagar Behere wrote:
> >>> On 09/23/2010 11:52 AM, Peter Soetens wrote:
> >>> >> So the cross compile progressed till 41% then stopped with
> >>> >> ----------
> >>> >> [ 41%] Building CXX object
> >>> >> rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plugi
> >>> >> n.di r/M QLib.cpp.o In file included from
> >>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mque
> >>> >> ue/M QSe rializationProtocol.hpp:50, from
> >>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mque
> >>> >> ue/M QLi b.cpp:42:
> >>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mque
> >>> >> ue/b in ary_data_archive.hpp: In member function 'void
> >>> >> RTT::mqueue::binary_data_iarchive::load_binary(void*, size_t)':
> >>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mque
> >>> >> ue/b ina ry_data_archive.hpp:245: error: 'stream_error' is not a
> >>> >> member of 'boost::archive::archive_exception'
> >>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mque
> >>> >> ue/b in ary_data_archive.hpp:259: error: 'stream_error' is not a
> >>> >> member of 'boost::archive::archive_exception'
> >>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mque
> >>> >> ue/b in ary_data_archive.hpp: In member function 'void
> >>> >> RTT::mqueue::binary_data_oarchive::save_binary(const void*,
> >>> >> size_t)':
> >>> >> /home/sagar/Downloads/orocos-toolchain-2.0.1/rtt/rtt/transports/mqu
> >>> >> eue/b ina ry_data_archive.hpp:434: error: 'stream_error' is not a
> >>> >> member of 'boost::archive::archive_exception' make[2]: ***
> >>> >> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plug
> >>> >> in.d ir/ MQLib.cpp.o] Error 1
> >>> >> make[1]: ***
> >>> >> [rtt/transports/mqueue/CMakeFiles/rtt-transport-mqueue-gnulinux_plug
> >>> >> in.d ir/ all] Error 2
> >>> >> make: *** [all] Error 2
> >>>
> >>> Do you know why the build fails here? Is it because of boost_1.44 which
> >>> is different from the recommended 1.38? Setting ENABLE_MQ to OFF is
> >>> okay for now because I don't see us communicating in real-time to
> >>> other processes. But it'd be good to know that it is there, in case we
> >>> need it.
> >>
> >> Oh yes, I overlooked this. The 'serialization' API of Boost changes with
> >> every Boost release, so we need to #ifdef this statement and provide
> >> alternative code for boost 1.44+. Any Boost 1.44 user may submit a
> >> patch :-)
> >
> > The API didn't change that much. The stream_error was split in an
> > input_stream_error and an output_stream_error.
> > Replacing all occurences by e.g. input_stream_error was enough for a
> > succesful compilation here. (using boost 1.44)
> >
> > http://www.boost.org/doc/libs/1_44_0/libs/serialization/doc/index.html
> >
> > I'm not that much of an RTT expert to know whether to change it to an
> > input or an output stream error, so I'll leave that up to you :)
>
> I tried to find the change in the boost API again but couldn't . patch
> in appendix is tested with boost 1.44.
>
> Steven

Applied, thanks.

Peter

first experience with 2.0

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

Applied, thanks.

Peter