tags:

views:

52

answers:

2

So I'm going nuts trying to figure this one out. Here's my basic setup:

I'm compiling a shared library with a bunch of core functionality that uses a lot of boost stuff. We'll call this library libpf_core.so. It's linked with the boost static libraries, specifically the python, system, filesystem, thread, and program_options libraries. This all goes swimmingly.

Now, I have a little test program called test_socketio which is compiled into a shared library (it's loaded as a plugin at runtime). It uses some boost stuff like boost::bind and boost::thread, and it's linked again libpf_core.so (which has the boost libraries included remember).

When I go to compile test_socketio though, out of all my plugins it gives me a linking error:

[ Building test_socketio ]
g++ -c -pg -g -O0  -I/usr/local/include -I../include test_socketio.cc -o test_socketio.o
g++ -shared test_socketio.o -lpy_core  -o test_socketio.so
Undefined symbols:
  "boost::lock_error::lock_error()", referenced from:
      boost::unique_lock<boost::mutex>::lock()   in test_socketio.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

And I'm going crazy trying to figure out why this is. I've tried explicitly linking boost::thread into the plugin to no avail, tried ensuring that I'm using the boost headers associated with the libraries linked into libpf_core.so in case there was a conflict there.

Is there something OSX specific regarding boost that I'm missing? In my searching on google I've seen a number of other people get this error but no one seems to have come up with a satisfactory solution.

Edit: Figured it out, OSX comes with boost 1.40 in /usr/local/include. Needed to put the headers for my version of boost somewhere and make sure that my plugins sees those first.

+1  A: 

You need to link to libboost_thread. Add the -lboost_thread switch.

KennyTM
A: 

When you link libpf_core.so against the static boost libraries, it's only going to get copies of the functions it actually uses. The linker doesn't bother to pull in functions that aren't referenced by the code in your library.

You need to link your test program against the boost libraries as well. You can't reliably "chain" the linkages.

John Kugelman
Hmm that may be the problem, I tried linking libboost_thread-mt.a against the plugin as well though and it didn't help. 10.5 has a set of boost libraries included with it, I'm playing with the notion that they're conflicting somehow.
gct