Dmitry Goncharov <dgoncharov@unison.com> writes:
The thread_data_base constructor is defined in a header file. Function make_external_thread_data() is defined in a .cpp file. This can lead to a situation when different libraries contain the definitions of these functions. The example below explains how this can happen and why this causes problems.
It always causes problems if your program has two incompatible definitions of the same structure. It's a violation of the One Definition Rule.
There is a library (e.g. libuser.so) which uses the Boost.Thread library. Since the thread_data_base constructor is defined in a header file libuser.so can contain its definition. Again, the size of thread_data_base object, that the thread_data_base constructor from libuser.so expects, depends on if libuser.so was built with _GLIBCXX_DEBUG defined or not.
An application cannot link agains both libboost_thread.so and libuser.so if these libraries were built with different _GLIBCXX_DEBUG definitions (or different alignment, etc). While loading the application the dynamic linker will use the definition of thread_data_base constructor either from libuser.so be or from libboost_thread.so. Whichever it finds first.
Can both the thread_data_base constructor and make_external_thread_data() reside either in a .cpp file or in a header?
That won't make any difference. All the thread structures that are defined in header files must have the same layout in the app as in the thread library, otherwise you will either get linker errors or (worse) runtime errors due to incorrect structure offsets. The solution is to use the same compiler flags when you build your application as when you build the boost thread library, to ensure that the structures have the same layout. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976