On 06/01/2012 09:54 AM, Sagar Behere wrote:
> On 05/31/2012 05:31 PM, Alexander Duda wrote:
>> On 05/31/2012 03:25 PM, Sagar Behere wrote:
>>> Oops, noticed that I replied only to Alex .. so sending it again on
>>> the mailing list.
>>>
>>> On 05/31/2012 02:03 PM, Alexander Duda wrote:
>>>> On 05/31/2012 09:18 AM, Alexander Duda wrote:
>>>>> On 05/30/2012 07:48 PM, Sagar Behere wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I'm trying to build rock stable (using the bootstrap.sh script to
>>>>>> build
>>>>>> the base system) on debian (stable 6.0 a.k.a squeeze, gcc-4.4.5)
>>>>>> amd64.
>>>>>> During autoproj update, there were issues about minimum package
>>>>>> versions, which I resolved by pulling in packages from the testing
>>>>>> repositories.
>>>>>>
>>>>>> The autoproj build process fails with: (pasting start of the error log
>>>>>> below, complete log at http://pastebin.com/82C8hrkN (pasting the log
>>>>>> file makes this email await moderation due to excess size)):
>>>>>>
>>>>>> ------
>>>>>> /home/sagar/excludes/rock/external/opencv/modules/highgui/src/cap_libv4l.cpp:303:
>>>>>>
>>>>>>
>>>>>> error: field ‘capability’ has incomplete ty
>>>>>> pe
>>>>>> /home/sagar/excludes/rock/external/opencv/modules/highgui/src/cap_libv4l.cpp:304:
>>>>>>
>>>>>>
>>>>>> error: field ‘captureWindow’ has incomplete
>>>>>> type
>>>>>> /home/sagar/excludes/rock/external/opencv/modules/highgui/src/cap_libv4l.cpp:305:
>>>>>>
>>>>>>
>>>>>> error: field ‘imageProperties’ has incomple
>>>>>> te type
>>>>>> /home/sagar/excludes/rock/external/opencv/modules/highgui/src/cap_libv4l.cpp:306:
>>>>>>
>>>>>>
>>>>>> error: field ‘memoryBuffer’ has incomplete
>>>>>> type
>>>>>> /home/sagar/excludes/rock/external/opencv/modules/highgui/src/cap_libv4l.cpp:
>>>>>>
>>>>>>
>>>>>> In function ‘int try_init_v4l(CvCaptureCAM_V4L*
>>>>>> , char*)’:
>>>>>> /home/sagar/excludes/rock/external/opencv/modules/highgui/src/cap_libv4l.cpp:421:
>>>>>>
>>>>>>
>>>>>> error: ‘VIDIOCGCAP’ was not declared in this scope
>>>>>> /home/sagar/excludes/rock/external/opencv/modules/highgui/src/cap_libv4l.cpp:421:
>>>>>>
>>>>>>
>>>>>> error: ‘struct CvCaptureCAM_V4L’ has no member named ‘capability’
>>>>>> /home/sagar/excludes/rock/external/opencv/modules/highgui/src/cap_libv4l.cpp:
>>>>>>
>>>>>>
>>>>>> In function ‘int try_init_v4l2(CvCaptureCAM_V4L*, char*)’:
>>>>>> -------
>>>>>>
>>>>>> I could test this on a "pure" debian testing machine if this error is
>>>>>> due to the mixup of debian stable and testing repositories, but that
>>>>>> seems unlikely.
>>>>>>
>>>>>> Also, I'm not going to use opencv for my project. I'm happy to simply
>>>>>> remove it from the build process if it has compile issues, but I'm not
>>>>>> familiar enough with autoproj to do that.
>>>>>>
>>>>>> Any ideas to resolve this?
>>>>> Hi,
>>>>>
>>>>> in this case the easiest way is to use the opencv version delivered by
>>>>> your OS distribution. Even if you do not use opencv in your project
>>>>> some
>>>>> tooling does and you had to exclude this tooling too if you want to
>>>>> remove opencv completely.
>>>>> * uncomment the following line (line 181) from
>>>>> autoproj/remotes/rock/libs.autobuild and call autoproj rebuild.
>>>>> Autoproj.add_osdeps_overrides 'opencv', :package =>
>>>>> 'external/opencv', :force => true
>>>>>
>>>>> Another way would be to manually trigger the opencv build which gives
>>>>> you probably the same error but know you could ask for help in an
>>>>> opencv
>>>>> forum. My best guess is a mixup between the one installed by rock
>>>>> (http://downloads.sourceforge.net/project/opencvlibrary/opencv-unix/2.3/O...)
>>>>>
>>>>>
>>>>> and a system one.
>>>>> * goto external/opencv/build, and call make
>>> First, I ran autoproj update to pull in your latest fixes.
>>>
>>> Then I noticed that I had libv4l-dev version 0.8.0-1 from the squeeze
>>> repository. On a hunch, I updated that to version 0.8.8-1 from testing
>>> and then ran make in external/opencv/build. That compiled, so maybe
>>> one of the early autoproj checks should grumble about the existing
>>> version of libv4l not being high enough? (It did that for other
>>> packages.)
>>>
>>>> In the lunch break I tried to use the opencv version provided by the
>>>> distribution. Unfortunately there was a bug in the CMakeLists.txt of
>>>> image_processing/frame_helper which was triggered by this change. I
>>>> pushed a bugfix to all branches including stable.
>>>>
>>>> If you run into this problem just call git pull insight the frame_helper
>>>> package or call autoproj update.
>>> After opencv compiled, I ran autoproj build to continue with rock
>>> installation. It failed with
>>> ---
>>> configuring CMake build system for image_processing/frame_helper
>>> Build failed
>>> image_processing/frame_helper: failed in configure phase
>>> 'cmake -DCMAKE_INSTALL_PREFIX=/home/sagar/excludes/rock/install
>>> -DCMAKE_MODULE_PATH=/home/sagar/excludes/rock/base/types/cmake
>>> -DCMAKE_BUILD_TYPE=Debug
>>> /home/sagar/excludes/rock/image_processing/frame_helper' returned
>>> status 1
>>> see
>>> /home/sagar/excludes/rock/install/log/image_processing/frame_helper-configure.log
>>> for details
>>> last 10 lines are:
>>>
>>> -- Found the following Boost libraries:
>>> -- graph: /usr/lib/libboost_graph-mt.so
>>> -- filesystem: /usr/local/lib/libboost_filesystem.so
>>> -- Boost version: 1.44.0
>>> -- Using the following Boost include directory: /usr/local/include
>>> -- Found the following Boost libraries:
>>> -- unit_test_framework: /usr/local/lib/libboost_unit_test_framework.so
>>> -- regex: /usr/local/lib/libboost_regex.so
>>> -- boost/test found
>>> -- Configuring incomplete, errors occurred!
>>> ---
>>>
>>> The frame_helper-configure.log mentions
>>> -----------
>>> -- found opencv, version 2.3.0
>>> -- checking for module 'libv4lconvert'
>>> -- package 'libv4lconvert' not found
>>> CMake Error at /usr/share/cmake-2.8/Modules/FindPkgConfig.cmake:266
>>> (message):
>>> A required package was not found
>>> Call Stack (most recent call first):
>>> /usr/share/cmake-2.8/Modules/FindPkgConfig.cmake:320
>>> (_pkg_check_modules_internal)
>>> CMakeLists.txt:28 (pkg_check_modules)
>>>
>>>
>>> -- checking for module 'libv4l2'
>>> -- package 'libv4l2' not found
>>> CMake Error at /usr/share/cmake-2.8/Modules/FindPkgConfig.cmake:266
>>> (message):
>>> A required package was not found
>>> Call Stack (most recent call first):
>>> /usr/share/cmake-2.8/Modules/FindPkgConfig.cmake:320
>>> (_pkg_check_modules_internal)
>>> CMakeLists.txt:32 (pkg_check_modules)
>>>
>>> -------------
>>>
>>> dpkg -l *v4l* shows
>>> ----
>>> sagar@maya:~$ dpkg -l *v4l*
>>> Desired=Unknown/Install/Remove/Purge/Hold
>>> |
>>> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>>>
>>> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>>> ||/ Name Version Description
>>> +++-=========================================-=========================================-==================================================================================================
>>>
>>> ii lib32v4l-0 0.8.8-1 Collection of video4linux support libraries (32
>>> bits)
>>> ii libv4l-0 0.8.8-1 Collection of video4linux support libraries
>>> ii libv4l-dev 0.8.8-1 Collection of video4linux support libraries
>>> (development files)
>>> ii libv4lconvert0 0.8.8-1 Video4linux frame format conversion library
>>> un xserver-xorg-video-v4l<none> (no description available)
>>> sagar@maya:~$ dpkg -l *v4l2*
>>> No packages found matching *v4l2*.
>>> ---------
>>>
>>> So the new question is: Is this due to a bug in the fix that you
>>> pushed, or am I missing something? I checked to see if a package like
>>> libv4lconvert0-dev exists, but it does not. Neither does anything with
>>> *v4l2*
>>>
>> No it has nothing to do with the fix I pushed. libv4l-dev does include a
>> package config for libv4l2 (see
>> http://packages.debian.org/squeeze/i386/libv4l-dev/filelist). Therefore
>> it seems that there is something wrong with your pkg-config. Can you try
>> 'pkg-config --list-all | grep libv4l2' from the console. You should get
>> a result similar to:
>> libv4l2 libv4l2 - v4l2 device access library
> Hmm, the problem was in the PKG_CONFIG_PATH. For amd64 systems, it
> should contain /usr/lib/x86_64-linux-gnu/pkgconfig; which wasn't there.
> I added it manually and now rock has compiled properly.
>
> On a related note, I also tried to install rock stable on a spanking new
> debian wheezy install in a virtual machine (also amd64). There were path
> issues there for some Qt libraries. The build failed with
> --------
> building gui/rock_widget_collection (5%)Build failed
> gui/rock_widget_collection: failed in build phase
> 'make -j2' re
> see
> /home/sagar/rock/install/log/gui/rock_widget_collection-build.log for
> details
> last 10 lines are:
>
>
> 'VIZKIT_PLUGIN_RUBY_PATH'='/home/sagar/rock/install/lib/vizkit:/home/sagar/rock/install/lib:/home/sagar/rock/install/lib/vizkit:/home/sagar/rock/install/lib'
> '_'='/home/sagar/rock/.gems/bin/autoproj'
>
> Fri Jun 01 09:03:48 +0200 2012: running
> make -j2
> [ 3%] Built target stream_aligner_widget
> [ 5%] Built target testWidget
> make[2]: *** No rule to make target `/usr/lib/libQtNetwork.so',
> needed by `src/librock_widget_collection.so'. Stop.
> make[1]: *** [src/CMakeFiles/rock_widget_collection.dir/all] Error 2
> make: *** [all] Error 2
> sagar@wheezy:~/rock$
> ---------
> This occurred for libQtGui, libQtSql, libQtNetwork, libQtCore. The
> reason is that in wheezy, these libraries are in
> /usr/lib/x86_64-linux-gnu/ and not /usr/lib/
>
> For the moment, I fixed it by manually creating symlinks, but this
> should really be taken care of by the build system.
According to http://qtnode.net/wiki/Qt4_with_cmake is the Qt4 support
maintained by
the KDE project for KDE4. Therefore I do not know why find_package is
returning in your case the wrong path.
So far we had no problems with building qt on any debian distrubution we
are using (squeeze,wheezy,sid) but I am
thankful for any hint.

>
> On a slightly different note, I see that one needs CORBA (omniorb),
> opencv, Qt and other things in order to install Rock. Most of it seems
> to be for the tooling, but I get the impression that Rock is rather
> "fat". Is this right? My intended deployment will be on a tiny gumstix
> overo platform (an embedded ARM processor) where both RAM and flash
> space are at a premium. Is it possible to build (or deploy) Rock with an
> 'embedded flavor' i.e. with minimum size and dependencies on other
> libraries?
You are absolutely right most of the stuff is needed for the tooling and
you can limit it to your custom need by changing
autoproj/manifest. Just uncomment the following lines to get rid of qt
and opencv. If you want to disable corba as well you wont have any benefit
over plain orocos as none of the rock tooling will work.
- rock/vizkit
- rock.tutorials

If your are interested in cross compiling have a look at
http://rock.opendfki.de/wiki/WikiStart/Toolchain/XcompiledRTT

Alex

>
> Thanks for all the help so far. I'll now work through the tutorials.
>
> Regards,
> Sagar