Ask Your Question

da-phil's profile - activity

2014-01-21 07:31:10 -0600 received badge  Famous Question (source)
2013-10-28 08:46:09 -0600 received badge  Nice Answer (source)
2013-10-28 08:41:55 -0600 received badge  Good Question (source)
2013-09-30 11:23:13 -0600 received badge  Notable Question (source)
2013-06-10 21:01:13 -0600 received badge  Popular Question (source)
2013-06-06 06:01:13 -0600 received badge  Taxonomist
2013-04-24 02:24:38 -0600 asked a question [fuerte] Updating ROS underlay fails

Hi!

I installed ROS fuerte from source and figured out some issues with the underlay, so I patched and recompilee it. Now I struggle to get it to compile, the cmake part is failing with the following output: I'm in ~/ros-underlay/build and invoke "cmake ../"

-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- +++ catkin
-- Found PythonInterp: /usr/bin/python (found version "2.7.3")
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking for include files CMAKE_HAVE_PTHREAD_H - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE 
-- Found gtest: gtests will be built.
TODO: implement add_roslaunch_check() in rostest-extras.cmake.
-- Building stack catkin
-- BUILD_SHARED_LIBS is on.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ~~         traversing stacks/projects in dependency order         ~~
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- +++ genmsg
-- Building stack genmsg
-- +++ genpy
-- Building stack genpy
-- +++ gencpp
-- Building stack gencpp
-- +++ genlisp
-- Building stack genlisp
-- +++ rospack
-- Building stack rospack
-- Rospack building shared objects.
-- Boost version: 1.46.1
-- Found the following Boost libraries:
--   system
--   filesystem
--   program_options
-- +++ std_msgs
-- Building stack std_msgs
-- std_msgs: 32 messages
-- +++ ros
-- Boost version: 1.46.1
-- Found the following Boost libraries:
--   thread
-- Building stack ros
CMake Error at build/cmake/rospack/rospack-config.cmake:67 (message):
  In project roslib I'm looking for rospack via find_package.  The source for
  rospack is present in workspace, but rospack is not a target.  Did you
  find_package() this thing before the subdirectory containing its code is
  included?

Does anybody have an idea whats happening there? Thanks in advance for any pointers!

Cheers Phil

2012-10-02 21:08:39 -0600 received badge  Famous Question (source)
2012-10-02 21:08:39 -0600 received badge  Notable Question (source)
2012-08-30 14:43:42 -0600 received badge  Famous Question (source)
2012-08-30 14:43:42 -0600 received badge  Notable Question (source)
2012-08-30 14:43:42 -0600 received badge  Popular Question (source)
2012-02-05 19:00:59 -0600 received badge  Popular Question (source)
2011-09-28 06:11:46 -0600 received badge  Teacher (source)
2011-09-28 06:11:46 -0600 received badge  Self-Learner (source)
2011-09-28 06:11:35 -0600 received badge  Nice Question (source)
2011-08-11 00:30:59 -0600 received badge  Supporter (source)
2011-04-18 22:20:41 -0600 commented answer Adjust RPATH for cross-compilation target
I fully agree on calling this approach "hackish" ;) however there is no nice and sophisticated solution in my mind, yet. you mentioned that troy is working on rosbuild2. i'm looking forward for seeing a more generic approach to build software with ROS where cross compilation and target deployment is only a usecase not a special treatment.
2011-04-17 21:17:18 -0600 commented answer Adjust RPATH for cross-compilation target
The problem is that /opt/ros/cturtle on my working machine is a global network-wide installation which is used by many other colleagues. Although I'm the maintainer with write-permissions within /opt/ros I don't want to make any changes to this directory at all. See my current approach in the answer below
2011-04-17 21:13:02 -0600 answered a question Adjust RPATH for cross-compilation target

Right now I'm just replacing the RPATH prefixes in the freshly created binaries by this little script which is part of the deployment. call it this way

> script /path/to/ros_node1 /path/to/ros_node2

and your executables will be replaced with new rpaths.

SEARCH_PATH="/home/phil/ros/cturtle"
REPLACE_PATH="/opt/ros/cturtle"

which chrpath > /dev/null
if [ $? != 0 ]; then
    echo "Couldn't find the program 'chrpath'. Maybe it's existant but not found in the PATH searchpath"
    echo "exit..."
    exit 1
fi

if [ $# -lt 1 ]; then
    echo "Please specifiy a list of files which you want to work on..."
    echo "e.g: \$ replace_rpath program1 program2"
    exit 1
fi

for FILE in $@ ; do
    echo "-- Preparing $FILE"
    if [ ! -e "$FILE" ] || [ ! -f "$FILE" ]; then
            echo "'$FILE' is either not a file or doesn't exist!"
    else
            chrpath -l $FILE  | sed -e "s+.*=++g" -e "s+${SEARCH_PATH}+${REPLACE_PATH}+g" | xargs -I {} chrpath -r {} $FILE
            if [ $? != 0 ]; then
                    echo "chrpath failed!"
            fi
    fi
done

Not nice, but at least a starting point. I'm still looking forward for other - not so brutal - solutions.

2011-04-15 01:48:30 -0600 commented answer Adjust RPATH for cross-compilation target
Unfortunately this approach doesn't work very well as we deploy software in the same /opt/ros/cturtle folders on different architectures (x86/arm) whereas /opt/ros/cturtle is also used on the working machines for a global x86 ROS installation. Right now I discovered the handy tool "patchelf"....
2011-04-14 20:03:50 -0600 received badge  Editor (source)
2011-04-14 09:24:10 -0600 received badge  Student (source)
2011-04-14 04:42:08 -0600 asked a question Adjust RPATH for cross-compilation target

Hi all,

right now I'm successfully using eros to build ROS nodes for my gumstix hardware, but there is only one minor issue:

ROS host installation is located here: /home/phil/ros/cturtle

ROS target installation is located here: /opt/ros/cturtle

Now I've got the problem of not finding ROS related dynamic libraries when executing the nodes on my target. All RPATHs in my binaries refer to /home/phil/ros/cturtle instead of /opt/ros/cturtle. Is there any convenient way of setting a different RPATH prefix during cross-compilation instead of adding all local lib/ directories within the ROS tree on the target system? I'm not too familiar with the ROS build system nor am I with cmake in general. That's the reason why I bother to ask here ;)

Any feedback is much appreciated!

Cheers Phil

2011-04-14 04:20:52 -0600 answered a question visualization_common/ogre links wrong libboost (host version)

Ok, my solution was simply to make use of "ccmake" in order to influence the cmake cache, subsitute the wrong libboost paths with the right ones and build again. Not nice but this problem was really driving me nuts in the meantime.

2011-03-23 06:05:21 -0600 asked a question visualization_common/ogre links wrong libboost (host version)

Hi all,

right now I'm using a ROS cturtle base installation which i compiled entirely from source for a SLED 11 (Suse Linux Enterprise Desktop) system. I don't want to depend on the system installed libboost library (which is very old) so I installed a up-to-date libboost in a local usr/ directory. So far it works pretty nice, but I discovered that some shared libraries are still linking against the system installed libboost (/usr/lib). I discovered that the root of all evil are the orgre libraries (libOgreMain.so, libOgrePaging.so, libOgreProperty.so, libOgreTerrain.so, libOgreRTShaderSystem.so) which are later linked against other visualization tools and hence inherit dependencies to the wrong libboost version.

I figured that the key to force ogre to use a local installed libboost should be within the global makefile (visualization_common/ogre/Makefile):

LFLAGS = $(shell rosboost-cfg --lflags thread) \ -lpthread

This however seems not to work, although the output of rosboost-cfg --lflags thread looks good. I'm not very familiar with CMake to fully comprehend the "magic" behind the build scripts & macros within the ogre build process. But somehow the lib-search-path within the LDFLAGS above is not considered as primary search path or even not considered at all. This is what I checked out so far:

  • setting BOOST_ROOT to my local "usr/lib" folder
  • adjusting ogre/CMake/Dependencies.cmake
    • OGRE_DEP_SEARCH_PATH to my local "usr/lib" folder
    • Boost_INCLUDE_DIRS to my local "usr/include" folder
    • Boost_LIBRARY_DIRS to my local "usr/lib" folder

Software versions

  • ROS: cturtle source installation from rosinstall
  • Host version of libboost: 1.36
  • Local version of libboost: 1.40
  • CMake version: 2.8.3

Maybe some of you guys have a clue what is going on there, or even have had the same problem.

Thanks in advance ;)

Cheers Phil