2005/11/17, Matthias Klose <[EMAIL PROTECTED]>:
> sorry for being a bit unclear. These *mt_alloc* symbols are exactly
> these we are looking for, so at least the package has to be
> rebuilt.
Understood. Thanks for clarifying this.
> AFAICS no bug asking for a package renaming has been filed.
I s
sorry for being a bit unclear. These *mt_alloc* symbols are exactly
these we are looking for, so at least the package has to be
rebuilt. AFAICS no bug asking for a package renaming has been filed.
Matthias
Damyan Ivanov writes:
> 2005/11/11, Matthias Klose <[EMAIL PROTECTED]>:
> > there are cur
2005/11/11, Matthias Klose <[EMAIL PROTECTED]>:
> there are currently about 1700 binary packages depending on
> libstdc++6, 150 library source packages and 182 app source packages
> have references to mt_alloc symbols.
I see firebird2 in your list. How did it get there?
I've run objdump -t agains
* Matthias Klose:
>> Does it change the internal representation of std::string, or some
>> other template instantiation provided by libstdc++?
>
> I don't see a change to the internal representation of std::string,
> I'm forwarding this upstream.
std::string seems to be fine because the instance
Nathanael Nerode writes:
> Matthias Klose wrote:
> > about 150. attached is a list of source packages, which either define
> > mt_alloc symbols or reference them. libraries depending on kdelibs do
> > not have to be renamed (about 30/40).
> Um, out of curiosity, why don't they? They didn't need to
Matthias Klose wrote:
> about 150. attached is a list of source packages, which either define
> mt_alloc symbols or reference them. libraries depending on kdelibs do
> not have to be renamed (about 30/40).
Um, out of curiosity, why don't they? They didn't need to be renamed
for 'c2' because KDE ha
On Wed, Nov 09, 2005 at 12:30:43PM +0100, Domenico Andreoli wrote:
> 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,
Steve Langasek writes:
> > * 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 p
On Wed, Nov 09, 2005 at 12:30:43PM +0100, Domenico Andreoli wrote:
> 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:
> > >
> > > The proposal by upstream is to configure libstdc++ to use the new
> > > allocator agai
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 o
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), ot
* Matthias Klose:
> 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.
Does it change the internal representation of std::string, or some
othe
* Matthias Klose ([EMAIL PROTECTED]) [051108 16:28]:
> 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.
>
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)
14 matches
Mail list logo
