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 against
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 see no
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
* 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 is
On Mon, Nov 14, 2005 at 11:32:15AM +0100, Christophe Prud'homme wrote:
can we start working on 1.33.1 ? or do you want to make some intermediary
release ?
i don't see any good reason to make any new upload to unstable until new
gcc 4.0 upload. and even when new gcc 4.0 is uploaded, we
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,
as
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 had
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 be
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
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
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 again (the
* 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.
*
* 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
other
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
14 matches
Mail list logo
