Ulrich Eckhardt wrote:
Now, what I did here was to create an additional file that can be included as "boost/thread/inplace_link.cpp". All that this file does is #include the sourcefiles from lib/thread/src. Now, in order to use threads, all you need to do is to include this file into exactly one translation unit, that's it. Really, that is all! Apart from static linking, this has an additional advantage: ABI independence.
If you have a bunch of C++ compilers on your machine, you need just as many SOs/DLLs, which all have to be built. Using GCC, those don't even have different names, so there is no way to use different ones alongside. Considering STLport, it can at least be distinguished from the native one, but STLport 5.1 is not binary compatible with STLport 5.0, so the problems remain.
(sorry this is a bit of a rant, but this topic has caused me *so* much pain in the past) I *very* strongly agree to that. ABI compatibility is already a problem in windows (I saw lots of refreences to msvc on this thread so it seemed to me that many people come from that side). But you can at least just dump the suitable boost .dll files into your application dir and windows does "The right Thing(tm)". On linux the situation is a totally different matter. There are two options if you distribute your application in source, neither of them practical: * Supply your own boost sources, and compile it alongside your project. Its probably easy enough to include the boost build, but with the time boost takes for a full build, do you really want to do that ? And if the boost build breaks do you want to do support the support calls? * Rely on the system supplied boost libs. Works reasonably well when your app is compiled form source, you only need to anticipate which version of boost will be installed. If you distribute binaries the situation becomes even worse: * Supply your own boost dynamic libs. This sounds easy, but considering things like LD_LIBRARY_PATH it is actually not failsafe and cannot be trusted. Apart from the fact that your boost libs need to be linked against the correct libstdc++ version, etc. or they won't work in the first place. * Rely on the system boost libs. This is right out. Unless you have exactly the same compiler version with exactly the same setup on your build machine as the enduser i would not expect the program to do anything. * Link statically. This only leaves you with the usual linux c++ ABI madness but at least boost will work properly. This is what we do, and I think its the only way that will work guaranteed. It introduces code bloat, but thats a small price to pay for developer sanity ;-) Of course, if i am going to link statically anyway, having header only libs is pretty much the same except that long link times are split into multiple longer compile times, and that i do not have to worry about which lib to include. So as has been said: shared objects have their advantages and their uses, and during the debugging cycle it would certainly speed things up, but for a final release build shared library only is not really a good option. In that sense: choice ftw. Michael Lacher