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 portable. 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@alinoe.com>