debug algo patch

[François Dumont]

In fact there is already a binary incompatibility, some tests are 
failing because of:

/home/fdt/dev/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:484: 
undefined reference to 
`__gnu_cxx::__enable_if<std::__is_char<char>::__value, 
std::ostreambuf_iterator<char, std::char_traits<char> > >::__type 
std::__detail::__copy_move_a2<false, char>(char const*, char const*, 
std::ostreambuf_iterator<char, std::char_traits<char> >)'

But of course it wouldn't be very complicated to restore exported 
__copy_move_a2 symbol namespace.

However to make the patch work I will have to do additional 
modifications that will surely introduce more binary incompatibility. 
Perhaps only to the debug mode but I already know that some maintainers 
don't want any binary incompatibility, even in debug mode.

Maybe we could do a branch for binary incompatible debug mode different 
from the one impacting normal mode ? However it will make branch 
management more complicated. Is there any plan to break binary 
compatibility in a version to come ?

François

On 05/24/2011 10:06 PM, Christopher Jefferson wrote:
> On 24 May 2011, at 20:46, François Dumont wrote:
>
>> ....
>>
>>     I am considering to start the SVN binary incompatible branch with this patch as soon as it works.
> Out of interest, which parts of this will be binary incompatible?
>
> It is obviously vital not to break the non-debugging containers and algorithms, but remaining internal functions won't do that, if you are careful.
>
> Further (and I certainly don't speak for everyone), as long as you put them in a different namespace, I wouldn't mind a binary-incompatable debugging library. I do not know if there has ever been an assumption of ABI compatibility in debug mode, but I certainly haven't assumed it. Others may of course disagree.
>
> Chris