[ros-users] [BUG REPORT] rosboost-cfg doesn't work well with ROS_BOOST_ROOT

Thu Sep 9 05:02:46 UTC 2010

Dear ros users,

I have a problem with rosboost-cfg. Here is the situation I encountered.

I'm using MontaVista Linux and had already installed boost at /usr/local
which is 1.36.0 and was used intensively by existing softwares. I have
installed cturtle_base using rosinstall. The ros requires boost which is
greater than or equal to 1.37.0. So I've installed boost 1.40.0 at
/opt/boost and set ROS_BOOST_ROOT to /opt/boost. I've managed to
successfully build 38 packages out of ros. Everything was going smoothly
upto this.

I was interested in pluginlib so I built it and tried pluginlib_tutorials
at
http://www.ros.org/wiki/pluginlib/Tutorials/Writing%20and%20Using%20a%20Simple%20Plugin

I tried to execute polygon_loader and got a seg fault.I tried to trace back
to a root cause using gdb and the core file. When loading executable, gdb
prints out these messages for loading shared libraries

---
...
Reading symbols from */opt/boost/lib/libboost_filesystem.so.1.40.0*...done.
Loaded symbols for */opt/boost/lib/libboost_filesystem.so.1.40.0*
Reading symbols from /opt/boost/lib/libboost_system.so.1.40.0...done.
Loaded symbols for /opt/boost/lib/libboost_system.so.1.40.0
Reading symbols from /lib/librt.so.1...Reading symbols from
/usr/lib/debug/lib/librt-2.5.90.so.debug...done.
done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libdl.so.2...Reading symbols from
/usr/lib/debug/lib/libdl-2.5.90.so.debug...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from */opt/boost/lib/libboost_regex.so.1.40.0*...done.
Loaded symbols for */opt/boost/lib/libboost_regex.so.1.40.0*
Reading symbols from /usr/local/apr/lib/libaprutil-1.so.0...done.
Loaded symbols for /usr/local/apr/lib/libaprutil-1.so.0
...
Core was generated by `./polygon_loader'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7d63d0f in
boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*,
std::string>,
std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*,
std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> >
>::find_imp (this=0xbff75724)
    at /usr/local/include/boost/regex/v4/perl_matcher_common.hpp:297
297        matcher_proc_type proc = s_find_vtable[type];
---

I got these stack trace when typed where

---
(gdb) where
#0  0xb7d63d0f in
boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*,
std::string>,
std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*,
std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> >
>::find_imp (this=0xbff75724)
    at */usr/local/include/boost/regex/v4/perl_matcher_common.hpp:297*
#1  0xb7d64118 in boost::regex_search<__gnu_cxx::__normal_iterator<char
const*, std::string>,
std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*,
std::string> > >, char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > > (first=
      {_M_current = 0x806dfec "[${severity}] [${time}]: ${message}"},
last={_M_current = 0x806e00f ""}, m=@0xbff75830, e=@0xbff7586c,
    flags=boost::regex_constants::match_default, base={_M_current =
0x806dfec "[${severity}] [${time}]: ${message}"})
    at */usr/local/include/boost/regex/v4/perl_matcher_common.hpp:229*
#2  0xb7d6421f in boost::regex_search<__gnu_cxx::__normal_iterator<char
const*, std::string>,
std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*,
std::string> > >, char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > > (first=
      {_M_current = 0x806dfec "[${severity}] [${time}]: ${message}"},
last={_M_current = 0x806e00f ""}, m=@0xbff75830, e=@0xbff7586c,
    flags=boost::regex_constants::match_default) at *
/usr/local/include/boost/regex/v4/regex_search.hpp:42*
#3  0xb7d67f90 in ros::console::Formatter::init (this=0xb7d70ec0,
fmt=0xb7d6af38 "[${severity}] [${time}]: ${message}")
    at /home/yskim/ros/ros/core/rosconsole/src/rosconsole/rosconsole.cpp:281
#4  0xb7d5e055 in ros::console::do_initialize () at
/home/yskim/ros/ros/core/rosconsole/src/rosconsole/rosconsole.cpp:418
#5  0xb7d5e794 in ros::console::initialize () at
/home/yskim/ros/ros/core/rosconsole/src/rosconsole/rosconsole.cpp:430
#6  0xb7d5ebb6 in __static_initialization_and_destruction_0
(__initialize_p=<value optimized out>, __priority=<value optimized out>)
    at /home/yskim/ros/ros/core/rosconsole/src/rosconsole/rosconsole.cpp:657
#7  0xb7d6aa95 in __do_global_ctors_aux () from
/home/yskim/ros/ros/core/rosconsole/lib/librosconsole.so
#8  0xb7d5c40d in _init () from
/home/yskim/ros/ros/core/rosconsole/lib/librosconsole.so
#9  0xb7f9d5b0 in call_init (l=0xb7e01950, argc=1, argv=0xbff75a64,
env=0xbff75a6c) at dl-init.c:81
#10 0xb7f9d6c4 in _dl_init (main_map=0xb7fab678, argc=1, argv=0xbff75a64,
env=0xbff75a6c) at dl-init.c:145
#11 0xb7f8f8ff in _dl_start_user () from /lib/ld-linux.so.2
---

As you can see in bold & blue text, rosconsole was compiled using
/usr/local/include/boost header but linked against /opt/boost/lib.

So I suspected that there was something wrong with rosboost-cfg.
When I executed 'rosboost-cfg --cflags', I got nothing but -L/opt/boost/lib
-Wl,-rpath,/opt/boost/lib  -lboost_regex for 'rosboost-cfg --lflags regex.'
I analyzed rosboost_cfg.py source and found that Version.__init__() has
strange code segment about is_system_install property as follows

self.is_system_install = os.path.split(self.include_dir)[0] == self.root

For my environment, self.include_dir == /opt/boost/include and self.root ==
os.path.split(self.include_dir)[0] == /opt/boost.
And the include_dirs() subroutine returns value for --cflags option as
follows

def include_dirs(ver, prefix = ''):
    if (*ver.is_system_install* or no_L_or_I):
        return ""

    return " %s%s"%(prefix, ver.include_dir)

I don't know what is_system_install exactly means but for my environment, I
definitely need value of -L/opt/boost/include for --cflags. So I modified
the code as follows

def include_dirs(ver, prefix = ''):
    if (no_L_or_I):
        return ""

    return " %s%s"%(prefix, ver.include_dir)

After this modification, I managed to execute polygon_loader successfully. I
think this modification works only for me.

Please, fix this problem.

TIA

- Yoonsoo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20100909/56dc5c96/attachment-0002.html>