[pkg-boost-devel] Re: libstdc++ configuratrion

[Domenico Andreoli]

On Tue, Nov 08, 2005 at 04:27:53PM -0800, Steve Langasek wrote:
> On Tue, Nov 08, 2005 at 04:01:11PM +0100, Matthias Klose wrote:
> > libstdc++6 is currently configured to use the mt allocator based on
> > discussions in April 2004 with upstream libstdc++ developers. This
> > configuration turned out to be a mistake (memory leaks and the
> > allocator is still buggy), other distributions did change back to the
> > new allocator (the default one) in mid-2005 (FC in July 2005). The
> > change does not have an effect on symbols exported from libstdc++, but
> > it does have an effect on symbols exported by libraries which use
> > containers (using an allocator) from the template headers.
> 
> > The proposal by upstream is to configure libstdc++ to use the new
> > allocator again (the default one).
> 
> > The change will break some libraries, as seen in #336114, which can be
> > fixed by rebuilding these libraries against a reconfigured libstdc++.
> 
> >  * Identify all library packages depending on libstdc++ and
> >    exporting *mt_alloc* symbols.
> 
> >  * Rebuild these libraries and depending packages. Note that
> >    partial upgrades won't work with this procedure. To make this work, we
> >    would have to change the package name for all libraries affected.
> 
> What do you propose as the new name for these library packages?
> (Apparently, these will then be the *real* "c2" libraries... but also
> incompatible with those already shipped by other Debian-derived distros
> under that name, such as Ubuntu...)  Do we have any notion of how many libs
> are affected by this?

with these news, i need to understand how boost debian package needs
to move.

currently unstable has boost 1.33.0, which would be ready for testing if
it did not depend on gcc >= 4.0.2-3.  my understanding is that gcc-4.0,
as it is now, will never enter testing, so neither current boost will.

once libstdc++ gets back to new allocator, boost will probably need
a change of name and new dependency version on gcc 4.0 (and a rebuild
of all of its rdepends, like kdeedu). in this case i would push boost
1.33.1, due to be released in few days, and take this wave of rdepends
rebuilds.

my issues are with current kdeedu 4:3.4.2-2.1 depending on boost 1.33.0
and already in testing, while boost 1.33.0 is not, and with undergoing
c++ transition, which i honestly did not follow. am i missing anything
here? thank you.

regards
domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50