From: Carlo Wood (carlo_at_[hidden])
Date: 2004-09-13 07:33:03
On Mon, Sep 13, 2004 at 12:55:54AM -0500, Aaron W. LaFramboise wrote:
> Carlo Wood wrote:
> >>3. User programs compiled for platform A, and linking with
> >> a shared versions of this library - do not need to be
> >> able to run on platform B (with same architecture)
> >> without recompilation.
> > I don't see any benefit in allowing any kind of binary
> > portability. Actually - I think that this is rather trivial
> > issue as I think that most of boost already enforces this.
> > It would restrict the design enormously and put unneccessary
> > strain on the efficiency of the implementation to maintain
> > an ABI interface for this library. Just added this topic
> > to make this clear once and for all ;).
> What do you mean by 'platform' and what do you mean by 'architecture'?
> Is this non-guarantee different from the usual non-guarantee of
> different compilers being binary incompatible?
I am afraid that this whole point is too trivial, I shouldn't
have added it: its not worth the confusion.
What I am trying to say is that an application that uses
boost.muliplexor will need a total recompile on every platform
it is supposed to run on - not only a separate compile of the
multiplexor library - but a separate compile of the application
itself as well. There will be no way that any part is binary
Basically one could demand that a statically linked application
that runs on intel - but uses 'dlopen' to load the multiplexor
library - should be able to run on both linux and i386-solaris
without recompilation. Apart from that being a ridiculous
demand - I think it will be impossible to write the library in
such a way that this can be supported. I don't think its worth
the time to go into the reason for that observation ;).
-- Carlo Wood <carlo_at_[hidden]>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk