[boost] ABI fixing and prefix/suffix headers (was the boost::signal sample crashes)

From: John Maddock (jm_at_[hidden])
Date: 2003-08-08 06:33:51

> The main problem with shared_ptr 1.30.x and below is that the single- and
> multithreaded versions are incompatible. The CVS version is now binary
> compatible on Windows, so 1.31 will "work" across different threading
> models; still, the correct default for Borland should probably be to do a
> multithreaded build.
>
> By the way, this can't be fixed with prefix/suffix headers.

Agreed, no-one is trying to fix that - threaded and non-threaded builds use
different run time libraries for both the Microsoft and Borland compilers -
mixing code that was built with threading turned on with code where it is
turned off will *always* cause ODR violations, even if you're not using
boost :-)

> > but by default the libraries are all built using
> > the default compiler option for the tool.  The inlined (header-only)
> > library are only tested against that default set, so why not enforce
> > that default set for all boost libraries?  If an individual library
> > author then wants to enforce another set (different alignment or
> > something) for optimisation purposes, then let then over-ride the
> > defaults,
>
> But I don't want to enforce a set. I want (for example) shared_ptr to use
> whatever set the user has specified and not to override his settings.

Which causes no end of issues for libraries with separate source, unless we
abandon having a build system altogether and just tell people to "build
everything yourself".

To put this in perspective for C++ Builder the following options effect the
ABI:

-b (on or off - effect emum sizes)
-Vx  (on or off - empty members)
-Ve (on or off - empty base classes)
-aX (alignment - 5 options).
-pX (Calling convention - 4 options)
-Vmx (member pointer size and layout - 5 options)
-VC (on or off, changes name mangling)
-Vl (on or off, changes struct layout).

In addition, there are a whole bunch of separate runtime libraries - 4 C
libraries, plus 2 STLPort versions on top (so 8 combinations).  And that's
not counting the optional diagnostic libraries or the optional use of Rogue
Waves STL.

So assuming we build libraries for the 8 runtime variants we can't control,
that still leaves 2*2*2*5*4*5*2*2=3200!!! ABI options for each runtime
variant.  Seriously we need to get a handle on this where we can - and
please don't forget users can always turn this off if they want to handle
the ABI themselves.

One final point - there was a reason that I moved regex to use automatic
library selection and ABI fixing - without it I was getting a tonne of
support requests along the lines of "Your library doesn't work, it just
crashes when I call anything", which almost always turned out to be caused
by ODR violations (either the user had changed an ABI option, or had linked
to the wrong runtime-library-build variant), these basically stopped
overnight once I modified my code to stop those (this was all in pre-boost
days BTW).

Convinced yet?

John.