PCL install links directly to boost installation directory somehow

Question

I have a very odd problem with the installation of PCL. Basically i have set up PCL, boost, cmake, flann etc.. it all builds and compiles correctly. I copied and built the ICP example and it builds just fine.

Here is where it gets weird. When I run the application I get the following error:

ldd:FATAL: Could not load library bin.v2/libs/system/build/qcc-4.4.2/
release/threading-multi/libboost_system.so.1.48.0

So libboost_system.so.1.48.0 exists in the /usr/local/lib path and is even linked earlier by the same application, ie. if i run ldd on the application i get the following linked library information:

$ ldd iterative_closest_point
./iterative_closest_point:
libboost_system.so => /usr/local/lib/libboost_system.so.1.48.0 (0xb8200000)
libboost_filesystem.so => /usr/local/lib/libboost_filesystem.so.1.48.0 (0xb8209000)
libboost_thread.so => /usr/local/lib/libboost_thread.so.1.48.0 (0xb8225000)
OTHER BOOST
libpcl_common.so.1.7 => /usr/local/lib/libpcl_common.so.1.7.1 (0xb82ea000)
libpcl_octree.so.1.7 => /usr/local/lib/libpcl_octree.so.1.7.1 (0xb838c000)
OTHER PCL
libstdc++.so.6 => /usr/qnx650/target/qnx6/x86/lib/libstdc++.so.6.0.13 (0xb9285000)
libm.so.2 => /usr/qnx650/target/qnx6/x86/lib/libm.so.2 (0xb8774000)
libc.so.3 => /usr/lib/ldqnx.so.2 (0xb0300000)
ldd:FATAL: Could not load library bin.v2/libs/system/build/qcc-4.4.2/release/threading-multi/libboost_system.so.1.48.0

So I did some investigation into what the hell PCL is looking for, what is bin.v2? It exists in the boost install directory????

Now here is where it just gets nuts, if i run the program with an absolute path from the boost install directory ie. where the bin.v2 folder exists:

qnx:/root/boost/boost_1_48_0# /root/experiments/checkPCL/iterative_closest_point

it works!! the program outputs the desired things. So i was like alright, lets run ldd here:

qnx:/root/boost/boost_1_48_0# ldd /root/experiments/checkPCL/iterative_closest_point

and we get this:

    libboost_system.so => /usr/local/lib/libboost_system.so.1.48.0 (0xb8200000)
MORE BOOST
libpcl_common.so.1.7 => /usr/local/lib/libpcl_common.so.1.7.1 (0xb82ea000)
MORE PCL
libstdc++.so.6 => /usr/qnx650/target/qnx6/x86/lib/libstdc++.so.6.0.13 (0xb9285000)
libm.so.2 => /usr/qnx650/target/qnx6/x86/lib/libm.so.2 (0xb8774000)
libc.so.3 => /usr/lib/ldqnx.so.2 (0xb0300000)
libboost_system.so.1.48.0 => /root/SMG/extern/libs/boost/boost_1_48_0/bin.v2/libs/system/build/qcc-4.4.2/release/threading-multi/libboost_system.so.1.48.0 (0xb87a7000)
libbz2.so.1.0.4 => /usr/lib/libbz2.so.1.0.4 (0xb87b0000)
libz.so.2 => /proc/boot/libz.so.2 (0xb87c2000)

The big long one is an absolute link into the boost filepath. I dont understand how PCL or ldd or anything could know about this path.

Does anyone have any ideas about how this could have happened? Also I need some solutions on how to fix it.

EDIT + ADD:

So recently, i am not sure what has changed but i have started to get the linker warning (not error):

/usr/qnx650/host/qnx6/x86/usr/bin/ntox86-ld: warning: bin.v2/libs/system/build/
qcc-4.4.2/release/threading-multi/libboost_system.so.1.48.0, needed by
/usr/local/lib/libboost_filesystem.so, not found (try using -rpath or -rpath-link)

so for whatever reason this is definitely attempting to link to bin.v2/.../... which is absolutely nuts, i have never seen this before? I have now scoured the boost install directory looking for things that might caused this. Nothing is unusual about how boost is installed.

As a further note i have made a simple example, a program that has main, includes and prints "it works", it has the following CMakeLists.txt:

find_package(PCL 1.2 REQUIRED)
find_package(Boost 1.48.0 COMPONENTS system filesystem REQUIRED)
add_executable (test test.cpp)
target_link_libraries(test
   ${BOOST_FILESYSTEM}  #Works
   ${PCL_DEFINITIONS}   #Works
   ${PCL_SEARCH_LIBRARIES} #If i add this it fails!
)

So it seems like PCL and boost are interacting badly and causing some truly crazy behavior!

Answer 1

This may not be of help but I have the same problem and here is what I found. That path is used by some boost libraries.

objdump -x libbost_filesystem-qcc-mt-1_55.so will show:

Dynamic Section:
NEEDED               bin.v2/libs/system/build/qcc/release/threading-multi/libboost_system-qcc-mt-1_55.so.1.55.0
NEEDED               libm.so.2
NEEDED               libstdc++.so.6
NEEDED               libc.so.3
INIT                 0x00004d40

Notice the full path.

I came upon this post while looking for a solution to this problem. I'm pretty sure it's a boost build related issue though, I'm also using QNX.

Answer 2

If it works from the absolute directory that contains bin.v2/libs/system/build/qcc-4.4.2/release/threading-multi/ then probably you have

• set LD_LIBRARY_PATH set to include . (the current working directory)
• added the current work directory using ldconfig somehow (there's several ways)

This is a bad idea in general. It's especially a bad idea if you're running as root (which it seems you do) because it can be exploited as a security hole.

The real issue would still appear to be that the linker embeds the full path for libboost_system. I don't know what causes this, but perhaps

• you specify the library as a concrete source (libboost_system.so.1.48.0 in stead of -lboost_system on most linkers/compilers)
• it is some kind of linker option (like -rpath?)

Hope this helps