This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] C++1x breaking the ABI in one more place :(
Paolo Carlini wrote:
> Anyway, in practice, are there any hopes that we can devise a concrete
> versioning mechanism in time for 4.6.0 allowing me to roll in the
> std::time_get changes without breaking the ABI? I'm not so optimistic ;)
I'm not that optimistic either. I'd be surprised if you could implement
all of the C++1x library changes without a single ABI break. Things
like std::string seem nearly insurmountable to me. I can imagine how an
old binary could work with the new library, but not how an old shared
object could work with the the new library and with a new application.
> I guess I will just keep that in my local trees, for now, and move to
> something, not that we lack things to implement, I just want to complete
> the work started with get_money / put_money...
I think there should be a libstdc++ branch that has all the ABI-breaking
changes on it. Then, when we're confident that we have all the changes,
we merge that branch to trunk and bump the .so version. Or add a
configure option so that you can build libstdc++ using the old or new
ABI. But, in any case, expect that distributors will provide both
versions of libstdc++ for a while, and that everyone will have to
rebuild their shared objects.
I'm happy to be proved wrong here! If we can make a single library that
can magically work with old and new shared objects at the same time,
that's great! But, if we can't, we shouldn't gradually morph the
library, introducing lots of little incompatibilities. Better to have
one big one.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713