Re: [boost] [system] Why is this not header-only?

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 
> 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