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!

you might want to clarify your platform (I'm assuming it is QNX? (Which I know nothing about) — sehe, May 06 '14 at 07:23
The LD_DEBUG environment variable is very helpful for debugging issues like this. Also, readelf is useful for determining embedded RPATH information. — Andy, May 15 '14 at 13:23
I use it to investigate the NEEDED and RPATH header elements. — Andy, May 15 '14 at 23:23
Same issue is discussed at http://stackoverflow.com/q/27312123/1048959 It is perhaps due to a bug in qcc. — Dan Stahlke, Jul 07 '15 at 17:27

score 4 · Answer 1 · answered Jul 16 '14 at 13:54

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.

score 3 · Accepted Answer · answered May 06 '14 at 07:21

3

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

answered May 06 '14 at 07:21

sehe

374,641
47
450
633

Thanks sehe, yes it is QNX which introduces some annoying complexities, i have tried to keep this separate. My LD_LIBRARY_PATH does not contain any relative paths, only /usr/local/lib. I believe that your second comment might be what is happening but this is all default library set up so unless it appears in boost or PCL somewhere i am not sure how this could have happened. – Fantastic Mr Fox May 06 '14 at 22:17
Also if i was linking with a relative path surely the build will fail when it cant find that library rather then failing at run time? – Fantastic Mr Fox May 06 '14 at 23:43
@Ben depends on where you're building from :) – sehe May 06 '14 at 23:45
what do you mean? The compiler? – Fantastic Mr Fox May 07 '14 at 00:03
Relative paths are relative to the current working directory. So, it could "just work" iff you build from the right directory. – sehe May 07 '14 at 00:05
Hahaha, that is true, but not very sustainable, I can also make a symbolic link to the bin.v2 directory but not a very desirable build system is it. I will need to fix this eventually. – Fantastic Mr Fox May 07 '14 at 00:07
@Ben I was merely responding to your question _"surely the build will fail when it cant find that library rather then failing at run time"_. Of course it wouldn't be advisable... – sehe May 07 '14 at 00:08
Well sure, but i am not building from a directory that the path would work. I am building from /root/experiments/ and for it to find ./bin.v2/.../libboost_system I found have to build in a directory with bin.v2 or a link to bin.v2. Since i am not doing this and the build is not failing (only at runtime, suggesting a dynamic library) I am not sure how where it is built affects this? – Fantastic Mr Fox May 07 '14 at 00:12

PCL install links directly to boost installation directory somehow

2 Answers2

Linked