From: Michael Lacher (michael.lacher_at_[hidden])
Date: 2007-04-05 04:25:06
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
(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
* 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk