Cross Compiling and Cross Debugging C++ with Eclipse from Debian Squeeze x64 to Debian Squeeze ARM (Raspberry Pi)

1. Introduction

I have received yesterday my Raspberry Pi (http://www.raspberrypi.org/) unit. 

Fig 1. Raspberry Pi connected

After complete successfully the basic setup (http://www.raspberrypi.org/quick-start-guide)  and after installing the Debian Squeeze distribution provided by the community (http://www.raspberrypi.org/downloads) I want to collaborate with this interesting project by writing a step by step tutorial that will show how to create a program on C++, and how to run it and debug it on our Raspberry.

2. Pre-Requirements


2.1 Eclipse

As usual Eclipse is not completely mandatory (You can directly write C++ files with almost any text editor), but It is a great help.


If you do not have JAVA yet, you have to install it. You can do it from the  package manager.

Download Eclipse IDE for C/C++ Developers from the official download page (http://www.eclipse.org/downloads/)


Unzip it and execute the 'Eclipse' file inside the 'Eclipse' folder


2.2 Arm Toolchain Cross Compilation

In order to generate programs that can run and be debugged on our RaspBerry, we need to install an appropriated compiler and an appropriated debugger.

2.2.1. Add the native compiler, make and ncurses library if they are not already in your development system.

sudo apt-get install gcc g++ make libncurses5-dev

2.2.2. Add the following line to /etc/apt/sources.list

deb http://www.emdebian.org/debian/ squeeze main

2.2.3. Install the following packages:

sudo apt-get install linux-libc-dev-armel-cross

sudo apt-get install libc6-armel-cross 

sudo apt-get install libc6-dev-armel-cross 

sudo apt-get install binutils-arm-linux-gnueabi

sudo apt-get install gcc-4.4-arm-linux-gnueabi

sudo apt-get install g++-4.4-arm-linux-gnueabi 

sudo apt-get install uboot-mkimage

2.2.4. Install the remote gdb:

sudo apt-get install gdb-arm-linux-gnueabi

warning: At this point you can find conflicts with the already installed gdb (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603347). If it is the case you will need to upgrade from gdb 7.0.1 (the currently installed) to gdb 7.4.1 (You can find it on http://ftp.gnu.org/gnu/gdb/). You will need to download it, configure it and install it, but do not worry too much, there are just 3 steps that can be found on the README file inside the downloaded file.

3. Our first Raspberry project

3.1 Open Eclipse and click on File --> C++ Project

3.2 Select Cross-Compile Project and give it a name and click on finish.

Fig 2. Our first Raspberry project on C++

3.3 Create a "src" folder inside the just created project and include a source file called "main.cpp" inside it. Fill the main.cpp with the following content:

Fig 3. Content and structure of our first Raspberry project on C++

4. Cross Compiling and executing the 'Hello World' project


4.1 Now that we have our project written, we need to compile it. In order to do that, open the project properties select settings and on the 'Cross G++ Compiler' change the command 'g++' by arm-linux-gnueabi-g++:

Fig 4. Cross project compiler

4.1 Do the same on the Cross G++ Linker:

Fig 5. Cross project linker

4.2 Build the project, (Ctrl+b) you should get a message on the console like the following one:

Fig 6. Cross project linker

As you can see, the project has been compiled and linked by using arm-linux-gnueabi-g++, that was the whole point. If you try to run the compiled from eclipse you wont see nothing happening. If you try to run it from the command line, it wont be recognize as an executable:

Fig 7. Error when executing the result from the host

But if you copy it and execute it from the Raspberry:

Fig 8. Project executed from Raspberry

Voila!! Our first C++ Cross-project running on Raspberry  :D

4. Cross Debugging the 'Hello World' project


Now that we have run successfully our project, let's see how we can debug it.


4.1 Install on your Raspberry gdbserver

sudo apt-get install gdbserver 

4.2 Run gdb server against your program, listening on the port 2345:

gdbserver :2345 MyFirstRaspBerryProject

If everything went ok, the system should get stuck waiting for a remote debug:

Fig 9. gdbserver started on the raspberry machine

4.3 From Eclipse click on the arrow besides the symbol of debug and select 'Debug Configurations'. Click twice on the tab 'C/C++ Remote Application' an new remote application will be automatically created:

Fig 10. New debug configuration

Click on the text 'Select other...' besides the button 'Apply'. On the new window, check the box 'Use configuration specific settings' and select  'GDB (DSF) Manual Remote Debuggin Launcher':

Fig 11. Manual Remote selection

Clicking on OK it will bring us to the previous screen. Set the main and debugger tabs as following:

Fig 12. Main Tab

Fig 13. Debugger Main Tab

Fig 14. Debugger Connection tab

Now you can click on the Debug button and:

Fig 15. Cross Debugging our project

Unit Testing with CppUnit and Eclipse

As I already mentioned in one of my previous posts, CppUnit is a powerful framework that allows us to automatize the unit testing execution.Unit testing is an extremely important activity in our daily development life, not only from a theoretical quality-related point of view but also from a practical perspective like ensuring the behavior of our code before refactoring, preventing fixed bugs to appear once again etc.

The idea behind CppUnit is to develop parallel classes that will be the ones in charge of testing our 'real' classes. But let's have a look with an example.

1. Installing CppUnit

The first step of course is to get the tool and install it. You can download the last version from sourceforge (at this time 1.12.1) :

http://sourceforge.net/projects/cppunit/files/cppunit/

Untar the downloaded file, and from a terminal move inside the resultant directory and execute the following commands:

./configure
make
sudo make install

2. Using CppUnit for testing our Shared Libraries


A. Creating a shared library to be tested


Now that CppUnit is installed in our system it is time to use it. As example, I will test a shared library that under Eclipse. You can find how to create shared libraries on this previous post:

http://linuxtortures.blogspot.fr/2012/03/shared-libraries-with-eclipse-on-8664.html

Basically open eclipse and click on File --> new, and under the opened dialog select Shared Library, and Linux GCC

As we are under a 64 bits architecture, do not forget to compile with -fPIC, otherwise you will get the following error:

/usr/bin/ld: ./Calculator.o: relocation R_X86_64_32S against `vtable for Calculator' can not be used when making a shared object; recompile with -fPIC

You can activate -fPIC compilation under eclipse by right click on your project and under properties check the following option:

Our library will contain a class 'Calculator' that implements two methods: add and sub (please note that both method are inlined for the shake of simplicity):

A. Creating the testing project

Now let's create our test project, that it will be just an an executable linked to our shared library and of course to the CppUnit framework.

First create a new executable project:

Now link your project against libdl, libcppunit and of course the result of the shared library that we are planning to test. You will need to include the folder where the shared library is generated on the library search path:

The libdl is needed in order to avoid errors of the kind:

/usr/local/lib/libcppunit.so: undefined reference to `dlsym'
/usr/local/lib/libcppunit.so: undefined reference to `dlopen'
/usr/local/lib/libcppunit.so: undefined reference to `dlclose'

You will also need to include the path to our shared library headers in order to use it:

B. Creating the testing class:

Once finished ((almost)) all the including and configuring steps let's focus now on the 'pure' testing procedure.

The most basic case is to just create a class that inherit from CppUnit::TestCase and perform all the needed 'ASSERTS' on the overridden method 'runTest()', then on the main method of our testing project we just need to create a 'CppUnit::TextUi::TestRunner'  and include our just created class as a test to be run:

Here below you can find the code for our test class:

And here the one corresponding to the main method (the one actually in charge of of execute the tests):

That's all, the last step you have to perform before running your test project is just to include your shared library on the environment of the run configuration:

Now you can run your testing project an have a look to the results on the console:

2. Making things more sophisticated by using TestFixture and TestSuite


What we have explained until now is quite nice and it should allows you to start writing your unit test within a cpp environment, but let's complicate the things a bit more and let's talk about testsuites and fixtures.

As you can see on the previous example, we are using the class TestCalculator and its overridden method runTest to create a test. This approach could be enough for most of the cases, but in some cases trying to test the functionality of a library by writing all the asserts in one method or by creating a lot of classes (one per test)  can lead to confusion.

Here is where the TestFixture and TestSuite suites arrive. A TestFixture, basically allows us to convert methods of a class into a testcase, and a TestSuite will allows us to group all those tests and execute them as if it were just one. But let's see all that with an example:

A. Modifying TestCalculator

Now our TestCalculator.h class is going to look like that:


#ifndef TESTCALCULATOR_H_
#define TESTCALCULATOR_H_


#include <Calculator.h>
#include <cppunit/TestFixture.h>
#include <cppunit/TestAssert.h>
#include <cppunit/TestCaller.h>
#include <cppunit/TestSuite.h>


class TestCalculator:  public CppUnit::TestFixture {
public:
TestCalculator();
virtual ~TestCalculator();


 static CppUnit::Test *suite()
 {
   CppUnit::TestSuite *suiteOfTests = new CppUnit::TestSuite( "CalculatorTestSuite" );


   suiteOfTests->addTest( new CppUnit::TestCaller<TestCalculator>(
                                  "Test Sum",
                                  &TestCalculator::testSum ) );
   suiteOfTests->addTest( new CppUnit::TestCaller<TestCalculator>(
                                  "Test Subtraction",
                                  &TestCalculator::testSub ) );
   return suiteOfTests;
 }


 void setUp()
 {
 }
 void tearDown()
 {
 }


private:
 Calculator calculatorToBeTested;


protected:
  void testSum()
  {
 CPPUNIT_ASSERT(calculatorToBeTested.add(1,2)==3);
  }
  void testSub()
  {
 CPPUNIT_ASSERT(calculatorToBeTested.sub(5,1)==4);
  }


};


#endif /* TESTCALCULATOR_H_ */


As you can appreciate there is a static method returning a class Test that indeed returns a TestSuite. This is can be easily understood by having a look to the following diagram:

Indeed it is a composite pattern (Design Pattern) so basically a TestSuite has the same type than TestCase and on the top of everything can indeed contains TestCases.

On the other hand, test caller also inherit from TestCase so with this statemen:


    suiteOfTests->addTest( new CppUnit::TestCaller<TestCalculator>(
                                   "Test Sum",
                                   &TestCalculator::testSum ) );


We area adding TestCases to our TestSuite on the form of a methods (testSum and testSub). It is also worth to mention that setUp method is called each time before executing the actual testMethod and tearDown right after executing it, allowing us to set some pre-conditions (in case of needed) release them.

The last modification we have to perform to have everything working is on our main method:


#include <iostream>
#include <cppunit/TestSuite.h>
#include <cppunit/ui/text/TestRunner.h>
#include "TestCalculator.h"
using namespace std;


int main() {


CppUnit::TextUi::TestRunner runner;
runner.addTest(TestCalculator::suite());
runner.run();


return 0;
}



We are now adding the suite returned from the static method to our runner. Here the results:

Note that now we are running two tests. In case we deliberately make one test fail:


  void testSum()
  {
 CPPUNIT_ASSERT(calculatorToBeTested.add(1,2)==4);
  }

Here the result, showing clearly the name of the test that failed, the line, and the assert.

Continuous Integration with Jenkins, Mercurial and CppUnit on C++

Hello again!! Today I am going to talk about Jenkins, an open source tool that enables the continuous integration and delivery for our projects. As usual we will explain on this post how to set up a basic configuration and have the tool working into a local environment, if you are looking for a more complex configuration you can download here for free the book 'Jenkins the definitive guide'.

Basically what we are following with the continuous integration is to set up an environment that periodically and automatically check out our code, builds it and pass a set of regression/unit tests.

Jenkins provides us with a set of features that allows that and much more, as automatic mails in case of broken builds, dashboards showing the tests results, CVS/Mercurial and others version control systems integration and on the top of everything a friendly web based interface allowing everybody to check the results and manage the system.

A. Installing Mercurial on Debian Squeeze

1. Download here the last release for debian

2. Add the key:

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -

3. Install the following dependencies:

sudo apt-get install daemon

4. Install the package we downloaded on the step number 1:

sudo dpkg -i jenkins_1.454_all.deb

5. Logs & PID. By default Jenkins is executed as a stand-alone server, you can find the logs and the process id on the following files:

/var/log/jenkins/jenkins.log
/var/run/jenkins/jenkins.pid

6. Jenkins is configured by default to listen on the port 8080, if you fulfilled the previous steps, you should be able to see your jenkins interface by typing 'localhost:8080' on your favorite web explorer:

B. Linking Jenkins with our Project across Mercurial


The way Jenkins interacts with our source code is across mercurial, once Jenkins is properly configured it checks out our code, into a temp folder, builds the source code and executes the test that we have previously configured.

First of all you will have to install and configure mercurial on your machine. You can have a look here in order to know how to do it.

1. Putting our code under mercurial:

Since the objective of this post is not learn how to use mercurial, we will create a 'local' repository in our working directory (in my case /home/javier/workspace/workspace64/workspaceSharedLibrary) by executing the following command from the previous folder:

hg init

Now our source code is under mercurial and therefore can be accessed by Jenkins, let's see how.

2. Installing the Mercurial Plugin on Jenkins:

The mercurial plugin is not installed by default. From the initial Jenkins web page, click on 'Manage Jenkins', and afterwards click on 'Manage Plugins'. Under the available tab, you should be able to find 'Jenkins Mercurial plugin'. Check it and click on the button 'Install without restart'.

C. Configuring a new job

Now we have everything we need to configure our first 'job'. In Jenkins world, a 'job' is a set of task (that can be defined on a shell script) that are automatically executed within a configurable period, typically those tasks are related with building and testing.

From the initial page (localhost:8080) click on 'New job'. Give a name to your (in my case 'My_firs_job') select 'Build a free-style software project' and click 'ok', a new page allowing configure your job should be displayed. On the first part of the screen we are configuring the Mercurial repository (the local one) that jenkins must check out:

By scrolling down, we set up the frequency of the job. By setting 'Poll SCM' and putting ***** on the Schedule we are indicating that each minute, jenkins must check if there have been changes on the code and if it is the case it must executes the job. In this case the build is defined on the shell file 'home/javier/SANDBOX/Jenkins/build'. We will see the content of this file on the next section.

Finally, by scrolling down again, we can set the list of emails that must be notified in case that a build is not broken.

D. Create the build file ( /home/javier/SANDBOX/Jenkins/build)

The most basic build file is the one that executes the makefile that eclipse generates automatically. The variable 'WORKSPACE' is set up automatically by jenkins and defines the temporally directory where the code is check out.

#!/bin/bash

echo "*********building************"

echo $WORKSPACE

cd $WORKSPACE/InitialTest/Debug

echo $PWD

make clean

make

E. Configure the mail


In order to allow mail sending we have to link our jenkins platform with a mail server. In this case I will use my gmail acount for this end.

From the initial jenkins page (localhost:8080) click on 'Manage Jenkins' and then on 'Configure System'. At the bottom of the page you can set E-mail Notification parameters:

D. Executing the job


Now everything is configured and you can manually execute your job:

From the initial Jenkins page, select your job and on the left side of the page click on 'Build now'. A new item will be created on the 'Build History':

By clicking on the Build History item, you can enter to the details of the build. The most interesting information can be found on the 'Console Output' :

Started by user anonymous
Building in workspace /var/lib/jenkins/jobs/My_first_job/workspace
[workspace] $ hg showconfig paths.default
[workspace] $ hg pull --rev default
[workspace] $ hg update --clean --rev default
6 files updated, 0 files merged, 0 files removed, 0 files unresolved
[workspace] $ hg log --rev . --template {node}
[workspace] $ hg log --rev 1633c8b2cc6ab2fd1b40a594eb3cb21b1b9277f6
[workspace] $ hg log --template "<changeset node='{node}' author='{author|xmlescape}' rev='{rev}' date='{date}'><msg>{desc|xmlescape}</msg><added>{file_adds|stringify|xmlescape}</added><deleted>{file_dels|stringify|xmlescape}</deleted><files>{files|stringify|xmlescape}</files><parents>{parents}</parents></changeset>\n" --rev default:0 --follow --prune 1633c8b2cc6ab2fd1b40a594eb3cb21b1b9277f6
[workspace] $ /bin/sh -xe /tmp/hudson7862122761400994217.sh
+ /home/javier/SANDBOX/Jenkins/build
*********building************
/var/lib/jenkins/jobs/My_first_job/workspace
/var/lib/jenkins/jobs/My_first_job/workspace/InitialTest/Debug
rm -rf  ./src/InitialTest.o  ./src/InitialTest.d  InitialTest


Building file: ../src/InitialTest.cpp
Invoking: GCC C++ Compiler
g++ -I"/home/javier/workspace/workspace64/workspaceSharedLibrary/MySharedLibrary" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/InitialTest.d" -MT"src/InitialTest.d" -o "src/InitialTest.o" "../src/InitialTest.cpp"
../src/InitialTest.cpp: In function ‘int main()’:
../src/InitialTest.cpp:19: warning: unused variable ‘value’
Finished building: ../src/InitialTest.cpp


Building target: InitialTest
Invoking: GCC C++ Linker
g++  -o "InitialTest"  ./src/InitialTest.o   -lopencv_core -lopencv_highgui -lopencv_imgproc -lopencv_features2d -lopencv_calib3d
Finished building target: InitialTest
Finished: SUCCESS


E. Setting Green Balls as success indicator:

By default Jenkins indicates a successful build with a blue ball. If you (like me) consider that green color is more appropriated for this end, you just need to install the 'Green Balls' pluging;

From the initial Jenkins page click on 'Manage Jenkins' then on 'Manage Plugins' and under 'Available' tab find the 'Green Balls' plugin. Select it and click on 'Install without restart'. In order to have the plugin working, you will need to clean the cache of your explorer.

F. Unit Tests


As final step we are going to set up a unit test project that will be automatically executed (as the build) each time that someone commit a change in the central repository.

The first thing we need is to install 'CppUnit'. CppUnit is an open-source project that provides us with a set of utilities allowing include statements like 'assert' in our code. You can find more information about CppUnit in the official project page:

http://sourceforge.net/projects/cppunit/

More information and examples can be found on the CppUnit cookbook:

http://cppunit.sourceforge.net/doc/1.8.0/cppunit_cookbook.html

1. Download and Install.

From the project page, download and untar the last version of the project (1.12.1).

From the untar directory, execute the following commands:

./configure
make
sudo make install

2. Create your test project.

Using eclipse, create a new C++ project and add the following libraries:

libcppunit.so
libdl.so

If you do not include the libdl.so library, you will receive the following errors at building time:


/usr/local/lib/libcppunit.so: undefined reference to `dlsym'
/usr/local/lib/libcppunit.so: undefined reference to `dlopen'
/usr/local/lib/libcppunit.so: undefined reference to `dlclose'


Your project settings should look like this:

3. Make a shell executing the test project and transforming the results

I will dedicate a whole post to CppUnit, but by the time being we will consider enough to have a project working and generating a resulting report test (you can find how to do this on the CppUnit cookbook)

Once we have developed our test project we just need to create a new shell script (/home/javier/SANDBOX/Jenkins/tests) that runs it and transforms the result into a new report 'readable' by Jenkins:

 #!/bin/bash
echo "*********building tests project************"
echo $WORKSPACE
cd $WORKSPACE/CppUnitProject/Debug
echo $PWD
make clean
make 
$WORKSPACE/CppUnitProject/Debug/CppUnitProject
xsltproc /home/javier/SANDBOX/Jenkins/transform.xsl $WORKSPACE/CppUnitProject/Debug/cpptestresults.xml > $WORKSPACE/testresults.xml

In the previous script we are just executing the auto-generated (by Eclipse) make file and applying a xslt transformation that generates 'testresults.xml' from 'cpptestresults.xml'. In order to do that you will need the transformation file (in our case /home/javier/SANDBOX/Jenkins/transform.xsl) with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" indent="yes"/>
    <xsl:template match="/">
        <testsuite>
            <xsl:attribute name="errors"><xsl:value-of select="TestRun/Statistics/Errors"/></xsl:attribute>
            <xsl:attribute name="failures">
                <xsl:value-of select="TestRun/Statistics/Failures"/>
            </xsl:attribute>
            <xsl:attribute name="tests">
                <xsl:value-of select="TestRun/Statistics/Tests"/>
            </xsl:attribute>
            <xsl:attribute name="name">from cppunit</xsl:attribute>
            <xsl:apply-templates/>
        </testsuite>
    </xsl:template>
    <xsl:template match="/TestRun/SuccessfulTests/Test">
        <testcase>
            <xsl:attribute name="classname" ><xsl:value-of select="substring-before(Name, '::')"/></xsl:attribute>
            <xsl:attribute name="name"><xsl:value-of select="substring-after(Name, '::')"/></xsl:attribute>
        </testcase>
    </xsl:template>
    <xsl:template match="/TestRun/FailedTests/FailedTest">
        <testcase>
            <xsl:attribute name="classname" ><xsl:value-of select="substring-before(Name, '::')"/></xsl:attribute>
            <xsl:attribute name="name"><xsl:value-of select="substring-after(Name, '::')"/></xsl:attribute>
            <error>
                <xsl:attribute name="message">
                    <xsl:value-of select=" normalize-space(Message)"/>
                </xsl:attribute>
                <xsl:attribute name="type">
                    <xsl:value-of select="FailureType"/>
                </xsl:attribute>
                <xsl:value-of select="Message"/>
                File:<xsl:value-of select="Location/File"/>
                Line:<xsl:value-of select="Location/Line"/>
            </error>
        </testcase>
    </xsl:template>
    <xsl:template match="text()|@*"/>
</xsl:stylesheet>

4. Setting jenkins to execute the new shell

Once everything is in place we just need to include a new shell in our Job. From the initial Jenkins page click on your existing job and on menu placed on the left, click on configure. On the build section click on 'Add Build Step' and select 'Execute shell'. Set the location of our script (in my case /home/javier/SANDBOX/Jenkins/tests) and save the changes.

Now when building our job and checking the console output you should see that the test unit project is executed:


*********building tests project************
/var/lib/jenkins/jobs/My_first_job/workspace
/var/lib/jenkins/jobs/My_first_job/workspace/CppUnitProject/Debug
rm -rf  ./src/CppUnitProject.o ./src/MyClass.o ./src/MyClassTest.o  ./src/CppUnitProject.d ./src/MyClass.d ./src/MyClassTest.d  CppUnitProject

Building file: ../src/CppUnitProject.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/CppUnitProject.d" -MT"src/CppUnitProject.d" -o "src/CppUnitProject.o" "../src/CppUnitProject.cpp"
Finished building: ../src/CppUnitProject.cpp

Building file: ../src/MyClass.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/MyClass.d" -MT"src/MyClass.d" -o "src/MyClass.o" "../src/MyClass.cpp"
Finished building: ../src/MyClass.cpp

Building file: ../src/MyClassTest.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/MyClassTest.d" -MT"src/MyClassTest.d" -o "src/MyClassTest.o" "../src/MyClassTest.cpp"
Finished building: ../src/MyClassTest.cpp

Building target: CppUnitProject
Invoking: GCC C++ Linker
g++  -o "CppUnitProject"  ./src/CppUnitProject.o ./src/MyClass.o ./src/MyClassTest.o   -lcppunit -ldl
Finished building target: CppUnitProject

Resources

http://jenkins-ci.org/
http://schneide.wordpress.com/2008/09/29/using-hudson-for-ccmakecppunit/
http://cppunit.sourceforge.net/doc/1.8.0/cppunit_cookbook.html#cppunit_cookbook
http://www.wakaleo.com/books/jenkins-the-definitive-guide

Shared Libraries with Eclipse on 86_64 (64 bits) systems

If you followed my previous post http://linuxtortures.blogspot.com/2012/02/shared-libraries-with-eclipse.html
where I explained how to develop shared shared libraries there are a couple of extra steps that you must follow if you want to do the same onto a 84_64 system.

A. Download the appropriated version of eclipse from the official download page.

The package deployed for debian amd64 (Eclipse-CDT) does not work very well, so in this case the trick of adding the backports repository will not be useful.

B. Eclipse is java-based so you can just untar the file and execute the 'eclipse' file inside:

If you find difficulties when executing eclipse, or eclipse environment generates errors most probably there are dependencies that are not fulfilled. A non very elegant solution could be install the eclipse-cdt from the backports (It will automatically install all the needed dependencies) and then uninstall it. Then you can should be able to execute your 'manually' downloaded eclipse without issues.

C. Making and compiling Shared libraries:

Here there is a slight difference regarding the previous post. If you want to make a shared library compile within a 64 bits system you will need the 'Position Independent Code' (basically it will add the options '-fPIC'  to g++, otherwise you will receive a nice error like the following:

/usr/bin/ld: ./MyClass.o: relocation R_X86_64_32S against `vtable for MyClass' can not be used when making a shared object; recompile with -fPIC

Fortunately Eclipse allows us  to make this in a graphical way (Right click on the shared library --> Properties) and check the following check-box:

That should make the work. If you are very interested on this option you can find more information here:

http://www.technovelty.org/code/c/amd64-pic.html

Image processing with OpenCV

Hi again!! Following the format of my previous posts I will try to show step by step how to install and configure the OpenCV libraries, one of main open source references regarding image and video processing.

A. Installing the dependencies on Debian Squeeze

1. CMake

sudo apt-get install cmake

2. pkg-config

sudo apt-get install pkg-config

3. GTK

sudo apt-get install libgtk2.0-cil libgtk2.0-cil-dev
sudo apt-get install libgtk2.0-0 sudo apt-get install libgtk2.0-dev

4. Miscellaneous dependencies

sudo apt-get install swig
sudo apt-get install libjpeg62 libjpeg62-dev
sudo apt-get install libtiff4  libtiff4-dev

sudo apt-get install libjasper1 libjasper-dev 

sudo apt-get install libpng12-0 libpng-dev

sudo apt-get install zlib1g zlib1g-dev

sudo apt-get install openexr

sudo apt-get install ffmpeg

sudo apt-get install libgstreamer0.10-0 libgstreamer0.10-dev

sudo apt-get install libv4l-0 libv4l-dev

sudo apt-get install libxine1 libxine-dev

sudo apt-get install libunicap2 libunicap2-dev

sudo apt-get install libdc1394-22 libdc1394-22-dev

sudo apt-get install libavcodec52 libavcodec-dev

sudo apt-get install libavutil49 libavutil-dev

sudo apt-get install libpostproc51 libpostproc-dev

sudo apt-get install libswscale0 libswscale-dev

sudo apt-get install libavfilter0 libavfilter-dev

B. Download the libcv libraries and untar it on a local directory. You can download it from here: http://opencv.willowgarage.com/wiki/

C. Compiling the libcv library and headers

cd /home/javier/Desktop/OpenCV-2.3.1/

mkdir release

cd release

cmake D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_EXAMPLES=ON ..

My results:

-- General configuration for opencv 2.3.1 =====================================

-- 

--     Built as dynamic libs?:     YES

--     Compiler:                   /usr/bin/c++

--     C++ flags (Release):          -Wall -pthread -march=i686 -ffunction-sections  -O3 -DNDEBUG  -fomit-frame-pointer -msse -msse2 -mfpmath=387 -DNDEBUG 

--     C++ flags (Debug):            -Wall -pthread -march=i686 -ffunction-sections  -g  -O0 -DDEBUG -D_DEBUG -ggdb3 

--     Linker flags (Release):

--     Linker flags (Debug):

-- 

--   GUI: 

--     GTK+ 2.x:                   YES

--     GThread:                    YES

-- 

--   Media I/O: 

--     ZLib:                       YES

--     JPEG:                       TRUE

--     PNG:                        TRUE

--     TIFF:                       TRUE

--     JPEG 2000:                  TRUE

--     OpenEXR:                    NO

--     OpenNI:                     NO

--     OpenNI PrimeSensor Modules: NO

--     XIMEA:                      NO

-- 

--   Video I/O:

--     DC1394 1.x:                 NO

--     DC1394 2.x:                 YES

--     FFMPEG:                     YES

--       codec:                    YES

--       format:                   YES

--       util:                     YES

--       swscale:                  YES

--       gentoo-style:             YES

--     GStreamer:                  NO

--     UniCap:                     NO

--     PvAPI:                      NO

--     V4L/V4L2:                   Using libv4l

--     Xine:                       NO

-- 

--   Other third-party libraries:

--     Use IPP:                    NO

--     Use TBB:                    NO

--     Use ThreadingFramework:     NO

--     Use Cuda:                   NO

--     Use Eigen:                  NO

-- 

--   Interfaces:

--     Python:                     YES

--     Python interpreter:         /usr/bin/python2.6 -B (ver 2.6)

--     Python numpy:               YES

--     Java:                       NO

-- 

--   Documentation:

--     Sphinx:                     NO

--     PdfLaTeX compiler:          NO

--     Build Documentation:        NO

-- 

--   Tests and samples:

--     Tests:                      YES

--     Examples:                   YES

-- 

--   Install path:                 /usr/local

-- 

--   cvconfig.h is in:             /home/javier/Desktop/OpenCV-2.3.1/release

-- -----------------------------------------------------------------

-- General configuration for opencv 2.3.1 =====================================

-- 

--     Built as dynamic libs?:     YES

--     Compiler:                   /usr/bin/c++

--     C++ flags (Release):          -Wall -pthread -march=i686 -ffunction-sections  -O3 -DNDEBUG  -fomit-frame-pointer -msse -msse2 -mfpmath=387 -DNDEBUG 

--     C++ flags (Debug):            -Wall -pthread -march=i686 -ffunction-sections  -g  -O0 -DDEBUG -D_DEBUG -ggdb3 

--     Linker flags (Release):

--     Linker flags (Debug):

-- 

--   GUI: 

--     GTK+ 2.x:                   YES

--     GThread:                    YES

-- 

--   Media I/O: 

--     ZLib:                       YES

--     JPEG:                       TRUE

--     PNG:                        TRUE

--     TIFF:                       TRUE

--     JPEG 2000:                  TRUE

--     OpenEXR:                    NO

--     OpenNI:                     NO

--     OpenNI PrimeSensor Modules: NO

--     XIMEA:                      NO

-- 

--   Video I/O:

--     DC1394 1.x:                 NO

--     DC1394 2.x:                 YES

--     FFMPEG:                     YES

--       codec:                    YES

--       format:                   YES

--       util:                     YES

--       swscale:                  YES

--       gentoo-style:             YES

--     GStreamer:                  NO

--     UniCap:                     NO

--     PvAPI:                      NO

--     V4L/V4L2:                   Using libv4l

--     Xine:                       NO

-- 

--   Other third-party libraries:

--     Use IPP:                    NO

--     Use TBB:                    NO

--     Use ThreadingFramework:     NO

--     Use Cuda:                   NO

--     Use Eigen:                  NO

-- 

--   Interfaces:

--     Python:                     YES

--     Python interpreter:         /usr/bin/python2.6 -B (ver 2.6)

--     Python numpy:               YES

--     Java:                       NO

-- 

--   Documentation:

--     Sphinx:                     NO

--     PdfLaTeX compiler:          NO

--     Build Documentation:        NO

-- 

--   Tests and samples:

--     Tests:                      YES

--     Examples:                   YES

-- 

--   Install path:                 /usr/local

-- 

--   cvconfig.h is in:             /home/javier/Desktop/OpenCV-2.3.1/release

-- -----------------------------------------------------------------

D. Installing the libraries and headers

make


sudo make install

E. Our first opencv project with Eclipse

1. Open Eclipse and add a new 'Hello World' C++ project

2. Include the following libraries (You can find more information about how to add shared libraries in my previous post: http://linuxtortures.blogspot.com/2012/02/shared-libraries-with-eclipse.html)

3. For our first project we will just open and display an image. Include the following code in your main method:

Note that it is supposed that it exists a picture called 'gnu-linux.jpg' on the folder /home/javier/Desktop/

Compile your project and run it. If you have have problems running your project:

error while loading shared libraries: libmytestsharedlibrary.so: cannot open shared object file: No such file or directory

Create the following file :

/etc/ld.so.conf.d/opencv.conf

Add the following line:

/usr/local/lib

And execute the following command:

sudo ldconfig

Explanations about all this process can be found as well in my previous post.

If everything went ok the system should have prompted your picture:

RESOURCES

Books:

http://www.amazon.com/Learning-OpenCV-Computer-Vision-Library/dp/0596516134

http://www.packtpub.com/opencv-2-computer-vision-application-programming-cookbook/book

Webs

http://opencv.willowgarage.com/wiki/