Ask Your Question
0

visualization_common/ogre links wrong libboost (host version)

asked 2011-03-23 06:05:21 -0600

da-phil gravatar image

updated 2011-04-03 14:09:55 -0600

tfoote gravatar image

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

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2011-04-14 04:20:52 -0600

da-phil gravatar image

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.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2011-03-23 06:05:21 -0600

Seen: 879 times

Last updated: Apr 14 '11