[RFH] libstdc++ compatibility configured with different allocators

Debian does configure libstdc++ with --enable-libstdcxx-allocator=mt , based on discussions in April 2004 on libstdc++. Fedora used that configuration as well, and in July 2005 went back to configure libstdc++ using the default (new) allocator due to outstanding problems with the mt allocator. I

Processed: Re: ant code completion generates nullpointer exception

Processing commands for [EMAIL PROTECTED]: > clone 337510 -1 -2 -3 Bug#337510: eclipse-ecj: ant code completion generates nullpointer exception Bug 337510 cloned as bugs 338599-338601. > reassign -1 kaffe Bug#338599: eclipse-ecj: ant code completion generates nullpointer exception Bug reassigned

LSB 3.0 compliance of libstdc++.so.6 independent of allocator?

Running the C++ tests of the lsb testsuite results in identical results for a libstdc++ configured with the standard allocator and one configured with the mt allocator. Building libraries like arts with these different configurations results in incompatible libraries (the ones using the libstdc++

Processed: ant code completion generates nullpointer exception

Processing commands for [EMAIL PROTECTED]: > close 337510 -1 -2 -3 Unknown command or malformed arguments to command. > reassign -1 kaffe Bug number -1 not found. > reassign -2 classpath Bug number -2 not found. > reassign -3 sablevm Bug number -3 not found. > reassign 337510 libgcj6 Bug#33751

Re: libstdc++ configuratrion

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