On 06/29/2012 11:37 AM, Thomas Roehr wrote:
> On 28.06.2012 23:43, Sagar Behere wrote:
>> On 06/19/2012 10:19 AM, Thomas Roehr wrote:
>>> On 16.06.2012 21:56, Sagar Behere wrote:
>>>> On 06/16/2012 09:23 PM, Sagar Behere wrote:
>>>>> On 06/16/2012 06:31 PM, Sagar Behere wrote:
>>>>>> On 06/11/2012 09:51 AM, Thomas Roehr wrote:
>>>>>>> On 09.06.2012 15:41, Sagar Behere wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I would like to cross-compile rock for a gumstix overo (ARM)
>>>>>>>> processor.
>>>>>>>> I looked at this page:
>>>>>>>>
>>>>>>>> http://rock.opendfki.de/wiki/WikiStart/Toolchain/XcompiledRTT#no1
>>>>>>>>
>>>>>>>> but it isn't very clear what I need to do. Specifically,
>>>>>>>>
>>>>>>>> 1. Do I first need to install rock for the native platform?
>>>>>>> Not necessarily Rock, but Autoproj.
>>>>>>>> 2. It seems I need to download the rtt.arm.tar.gz and
>>>>>>>> install_scripts.tar.gz from that page. The page says to extract the
>>>>>>>> rtt.arm tarball to the autoproj folder and add rtt.arm to the
>>>>>>>> manifest
>>>>>>>> file. But which manifest file? If I start with an empty folder and
>>>>>>>> download the bootstrap.sh, then that is all I have.. no manifest
>>>>>>>> files.
>>>>>>>> So am I supposed to do sh bootstrap.sh first? But if I do that,
>>>>>>>> won't it
>>>>>>>> try to build for the native platform? Should I kill the 'sh
>>>>>>>> bootstrap.sh' at some point?
>>>>>>> The manifest file of autoproj is meant here. Usually found in
>>>>>>> autoproj/manifest
>>>>>>> after the bootstrap. You can stop just after bootstrap (without
>>>>>>> building
>>>>>>> all packages).
>>>>>>>
>>>>>>>> 3. When do I do the stuff with the install_scripts ?
>>>>>>> After bootstrapping and adding the rtt.arm (the package_set) to the
>>>>>>> autoproj configuration.
>>>>>>
>>>>>> The cross-compile still isn't working, but maybe I am close. Here are
>>>>>> the detailed steps I took. If/When I am able to get the whole
>>>>>> cross-compile working, these steps could be put on some wiki.
>>>>>>
>>>>>> Could someone tell me what is going wrong?
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Sagar
>>>>>> **********
>>>>>> Notes: fresh install of debian wheezy amd64. After install, the
>>>>>> following packages were installed
>>>>>>
>>>>>> sudo aptitude install build-essential autoconf automake cmake ruby1.8
>>>>>>
>>>>>> after that
>>>>>>
>>>>>> 1. mkdir ~/arm-rock;cd ~/arm-rock;wget
>>>>>> http://gitorious.com/rock/buildconf/blobs/raw/master/bootstrap.sh;
>>>>>>
>>>>>> 2. edit bootstrap.sh and # out lines as follows because we are
>>>>>> going to
>>>>>> cross-compile and there do not want the native build to happen.
>>>>>>
>>>>>> #if test "x$@" != "xlocaldev"; then
>>>>>> # . $PWD/env.sh
>>>>>> # autoproj update
>>>>>> # autoproj fast-build
>>>>>> #fi
>>>>>>
>>>>>> sh bootstrap.sh; I chose 'all' for osdeps, git, stable, gnulinux,
>>>>>> omniorb, no ocl compatibility
>>>>>>
>>>>>> 3. wget
>>>>>> http://rock.opendfki.de/raw-attachment/wiki/WikiStart/Toolchain/Xcompile...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> wget
>>>>>> http://rock.opendfki.de/raw-attachment/wiki/WikiStart/Toolchain/Xcompile...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 4. cd autoproj; tar zxvf ../rtt.arm.tar.gz
>>>>>>
>>>>>> 5. edit manifest and add rtt.arm to package set. Comment out
>>>>>> gui/vizkit
>>>>>> because we don't care about the tooling for now.
>>>>>>
>>>>>> 6. cd ~/arm-rock;mkdir arm; cd arm; tar zxvf
>>>>>> ../install_scripts.tar.gz;
>>>>>>
>>>>>> 7. Install the codesourcery tools manually because automated
>>>>>> installer
>>>>>> WILL fail. A number of workarounds are needed, as shown below.
>>>>>>
>>>>>> 7.1 sudo chown -R sagar. /opt;mkdir /opt/codesourcery
>>>>>> 7.2 sudo apt-get install ia32-libs; skip if not on amd64 systems
>>>>>> 7.3 sudo dpkg-reconfigure -plow dash; select NOT to use dash as
>>>>>> default
>>>>>> shell.
>>>>>> 7.4
>>>>>> cd /some/tmp/dir; wget
>>>>>> https://sourcery.mentor.com/sgpp/lite/arm/portal/package6490/public/arm-...
>>>>>>
>>>>>>
>>>>>>
>>>>>> chmod +x arm-2010q1-202-arm-none-linux-gnueabi.bin
>>>>>> 7.5 ./arm-2010q1-202-arm-none-linux-gnueabi.bin -i console; skip
>>>>>> the -i
>>>>>> console part if using gui
>>>>>>
>>>>>> During the install, choose 1 for typical installation, use
>>>>>> /opt/codesourcery/ as the installation folder and (optionally) 4
>>>>>> Don't
>>>>>> create links
>>>>>>
>>>>>> 8. cd ~/arm-rock/; source env.sh; autoproj envsh;
>>>>>> 9. cd ~/arm-rock/arm/install_scripts/; source ~/arm-rock/env.sh; ruby
>>>>>> build-rtt.rb
>>>>>>
>>>>>> Past the step, I get the following output. Specifically, the
>>>>>> following
>>>>>> lines are interesting:
>>>>>>
>>>>>> sh: bjam: command not found
>>>>>>
>>>>>> also there are errors about idl/python/omniorb. Perhaps I have not
>>>>>> installed some packages? The full output is
>>>>>
>>>>> <snipped: see previous thread for full error log>
>>>>>
>>>>> At this point, I gave up on the automated method.
>>>>>
>>>>> Next, I did aptitude install python2.7-dev; and proceeded as follows
>>>>>
>>>>> The steps so far had created the folders boost, xerces and omniorb in
>>>>> ~/arm-rock/arm and I went in there and manually compiled all three by
>>>>> following the steps for the raw compilation at
>>>>> http://rock.opendfki.de/wiki/WikiStart/Toolchain/XcompiledRTT#no1
>>>>>
>>>>> Everything complied fine. Then I went to ~/arm-rock/tools/rtt/build (I
>>>>> assume that this is the required version of RTT and I did not do a git
>>>>> checkout) and followed the steps for cross-compiling RTT. While
>>>>> compiling, I get the following error:
>>>>> -------
>>>>> [ 45%] Building CXX object
>>>>> rtt/CMakeFiles/orocos-rtt-gnulinux_dynamic.dir/extras/dev/HomingInterface.cpp.o
>>>>>
>>>>>
>>>>>
>>>>> make[2]: *** No rule to make target
>>>>> `/home/sagar/arm-rock/install/lib/libxerces-c.so.28', needed by
>>>>> `rtt/liborocos-rtt-gnulinux.so.2.5.0'. Stop.
>>>>> make[2]: *** Waiting for unfinished jobs....
>>>>> [ 45%] Building CXX object
>>>>> rtt/CMakeFiles/orocos-rtt-gnulinux_dynamic.dir/extras/dev/io.cpp.o
>>>>> make[1]: *** [rtt/CMakeFiles/orocos-rtt-gnulinux_dynamic.dir/all]
>>>>> Error 2
>>>>> make: *** [all] Error 2
>>>>> sagar@wheezy:~/arm-rock/tools/rtt/build$
>>>>> -------
>>>>>
>>>>> It seemed to insist on libxerces-c.so.28, so I
>>>>> cd ~/arm-rock/install/lib; ln -s libxerces-c-3.1.so libxerces-c.so.28
>>>>>
>>>>> and then did make && make install.
>>>>>
>>>>> Everything compiled. Yippieee!
>>> I just updated the install scripts, however this is for crosscompilation
>>> of RTT - see comments below.
>>> In any case let me know if you encounter problems using them.
>>>>>
>>>>> So the next question is: Now what? I have a folder ~/arm-rock/install
>>>>> that has boost, omniorb, xerces and orocos-rtt all crosscompiled and
>>>>> some more stuff in /opt/codesourcery/ and I can copy both these
>>>>> folders
>>>>> over to the gumstix rootfs. But from there on, will I be able to
>>>>> follow
>>>>> the rock tutorials on the gumstix? That seems unlikely. Aren't there
>>>>> other tools (orogen, for example) that the default bootstrapping
>>>>> process
>>>>> builds? What do I need to do to come to the same level that the
>>>>> default
>>>>> 'sh bootstrap.sh' procedure achieves when not cross-compiling?
>>>>
>>>>
>>>> rock-create-lib basics_tutorial/message_driver
>>>>
>>>> works, but when I try to compile it using
>>>>
>>>> amake basics_tutorial/message_driver/
>>>>
>>>> It naturally tries to build the whole of rock for the host system. I
>>>> looked at the CMakefile in basics_tutorial/message_driver/src/ but the
>>>> details of the build are hidden away in the rock_library and
>>>> rock_executable macros. I am guessing those will have to be edited so
>>>> the CC and CXX point to the cross-compiler? How is that done?
>>> The outline given on
>>> http://rock.opendfki.de/wiki/WikiStart/Toolchain/XcompiledRTT is
>>> dedicated to cross compiling RTT. Cross-compiling whole of ROCK is still
>>> on our Todo list - so I am afraid I cannot outline you a smooth
>>> crosscompilation-process for this right now - I missed to clarify that
>>> in my first reply.
>>>
>>> While already tried to use qemu but it gave not much of an advantage
>>> (time wise), so currently we crosscompile only a very selected set of
>>> packages such as RTT and compile the rest on the target system. This way
>>> we also avoided to dig into dependency management, cross compiling the
>>> ruby bindings, etc yet.
>>
>> D'uh! So the only advantage of doing all this is to reduce time for
>> the RTT compilation (which is only done once anyway)?
> Currently, yes.
>> Is there no way (yet) for following along with the rock tutorials,
>> using the commands mentioned in those tutorials, but generating ARM
>> binaries instead of native x86 ones?
> Correct, no streamlined cross-compilation process available.
>>
>> I am not particularly concerned about the time needed for the one-time
>> RTT compilation. I left the autoproj build system running for a whole
>> day on the gumstix and I can live with that.
>>
>> The main problem is that when I do the rock tutorials (on the
>> gumstix), building basics_tutorial/orogen/message_producer (i.e.
>> compiling the message_producer.orogen, I haven't even written any C++
>> code yet) from the tutorial takes ~20 minutes on the gumstix. That is
>> too long, and therefore it doesn't seem reasonable to code+compile my
>> system's components/tasks on the gumstix.
> Why are doing the tutorials on the gumstix initially?

Because I'm a bit afraid of investing a lot of time on Rock on an x86
host, and later realize that it won't work on my target platform. If I
have a basic program up and running on the gumstix+Xenomai, then my
confidence in Rock increases because I know that "It'll work." and I can
switch back to exploring Rock more, on the native x86 host. As of now, I
have spent several weeks understanding/cross-compiling/native-compiling
Rock and but I still haven't been able to get the simplest HelloWorld
type of component running on my gumstix+Xenomai setup. I'm ever so
close.. last night I had a compiled component, but Xenomai refuses to
run it with error "Xenomai: process memory not locked (missing mlockall?) "

I am now considering cooking my own framework from scratch using Xenomai
tasks and fifos, while fiddling with Rock side by side. This is a pity
because Rock seems to be exactly what I need, but the amount of work
needed to get it running is getting overwhelming.

>> So what workflow do you adopt when coding/compiling your RTT
>> components? Do you cross-compile them at all, or do you simply do
>> compilation on the gumstix?
> Do everything you need on your workstation, i.e. development and main
> testing. Update pkg on gumstix, build, test and verify there.
> Main development is done on our workstations (without crosscompilation).

Ah, but my program involves accessing lots of i/o boards and other
hardware that is only present on the gumstix embedded platform. I write
a little bit of code, compile+execute it, then repeat the process.
Dumping the code on the gumstix and compiling it there every few minutes
is not an option.

>> I am willing to live with a situation where I do
>> rock-create-orogen /path/to/component on the gumstix, then copy the
>> resulting folder to my quad-core amd64 workstation, write the C++
>> code, cross-compile it, then copy it back to the gumstix and execute.
>> The question then is: How do I cross-compile it on the workstation?
>> Which parts of the build system should be modified (and how) in order
>> that I can just call amake and have a cross-compiled result?
> That would mean we can 'Rock'-crosscompile - but also my previous
> comments on CMAKE_TOOLCHAIN_FILE as a first step

Okay, I'll look explore how it's possible to use this method to
cross-compile only the orogen component+dependencies.

> rock-create-X does not create any arch dependent files (and for orogen
> it only generates the spec and the manifest), so no need to call it only
> on the gumstix
>>
>> It would be really useful if the whole of Rock can be cross-compiled
>> and this in built into autoproj.
> Ack
>> xapt is available in squeeze-backports, wheezy and sid, as well as
>> dpkg-cross. Cross-compilation toolchains are available for all debian
>> flavors using the emdebian toolchain
>>
>> http://wiki.debian.org/EmdebianToolchain
>>
>> so the codesourcery toolchain isn't required. [ Once can simply
>> apt-get install g++-4.4-arm-linux-gnueabi ]
>>
>> Let me know if I can help with improving the build system so that
>> cross-compiling and deploying can be made simpler.
> Thx, my collegue in cc might contact you on this - he is mainly in
> charge of the crosscompilation procedure

Ack.

/Sagar

> Best
> Thomas
>>
>> /Sagar
>>
>>> CMake in general allows you use the CMAKE_TOOLCHAIN_FILE to setup for
>>> cross-compilationhttp://www.cmake.org/Wiki/CMake_Cross_Compiling . This
>>> is already used for the RTT compilation part: cmake
>>> -DCROSS_COMPILE=arm-none-linux-gnueabi ... -DCMAKE_TOOLCHAIN_FILE= ...
>>> and works for the rest of the C++ packages build with CMake (excl. the
>>> ruby bindings), e.g. set in autoproj/overrides.rb
>>>
>>> Autobuild::Package.each do |name, pkg|
>>> if pkg.kind_of?(Autobuild::CMake)
>>> pkg.define "CROSS_COMPILE", "arm-none-linux-gnueabi-"
>>> pkg.define
>>> "CMAKE_TOOLCHAIN_FILE","<yourpath>/arm-none-linux-gnueabi.cmake"
>>> end
>>> end
>>>
>>> e.g. for drivers/message_producer you would have to build base/types
>>> first (without sisl)
>>>
>>>
>>> Best
>>> Thomas
>>>
>>>>
>>>> Also, rock-create-orogen basics_tutorial/orogen/message_producer gives
>>>> -------
>>>> sagar@wheezy:~/arm-rock$ rock-create-orogen
>>>> basics_tutorial/orogen/message_producer
>>>> /usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
>>>> `gem_original_require': no such file to load -- typelib (LoadError)
>>>> from /usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
>>>> `require'
>>>> from /home/sagar/arm-rock/tools/orogen/lib/orogen/base.rb:5
>>>> from /usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
>>>> `gem_original_require'
>>>> from /usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
>>>> `require'
>>>> from /home/sagar/arm-rock/tools/orogen/lib/orogen.rb:3
>>>> from /usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
>>>> `gem_original_require'
>>>> from /usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in
>>>> `require'
>>>> from /home/sagar/arm-rock/tools/orogen/bin/orogen:3
>>>> /home/sagar/arm-rock/base/scripts/bin/rock-create-orogen: line 25: cd:
>>>> basics_tutorial/orogen/message_producer: No such file or directory
>>>> -------
>>>>
>>>> There is one thread that mentions this error, but not a solution
>>>>
>>>> http://www.orocos.org/forum/rtt/rtt-dev/r-rock-dev-build-fails-unknown-c...
>>>>
>>>>
>>>>
>>>> My ultimate wish is to have a build setup where I can use the
>>>> cross-compilation toolchain similar to the way the native toolchain is
>>>> used on the host system, then copy the contents of some folder where
>>>> the cross-compiled arm binaries are make install'ed, to the gumstix
>>>> and execute them there.
>>>>
>>>> Cheers,
>>>> Sagar
>>>
>>>
>>
>
>