[Bug libstdc++/21072] base allocator change shared object issues

[pcarlini at suse dot de]

--- Comment #9 from pcarlini at suse dot de  2006-10-08 01:32 ---
No open issues.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072

[Bug libstdc++/21072] base allocator change shared object issues

[bkoz at gcc dot gnu dot org]

--- Comment #8 from bkoz at gcc dot gnu dot org  2005-11-08 23:12 ---

We'd certainly not forget about this on the branch. 

However, I decided to just go ahead and do this anyway, because it is a change
in behavior but mostly because it seems to be confusing people/distros WRT what
allocator choices should be standard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072

[Bug libstdc++/21072] base allocator change shared object issues

[matz at suse dot de]

--- Comment #7 from matz at suse dot de  2005-11-07 19:59 ---
Of course not.  But unaware people trying trunk currently on distros which
provided 3.4 or 4.0 will get non-obvious problems, and I'm not sure if that's
a good idea (ignoring this problem 4.0 and trunk are nearly compatible, and
4.0 compiled programs work with the trunk libstc++, which has the same
SOname like the 4.0 one).  I think the only way to switch to the 'mt'
allocator by default for the future without API issues would be to rename
it to 'new', and not via some configure arguments.

Another reason is that this switching back of the default allocator is
not forgotten when 4.1 branches, which I think is necessary anyway, so that
4.1 libs are compatible with 4.0 programs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072

[Bug libstdc++/21072] base allocator change shared object issues

[bkoz at gcc dot gnu dot org]

--- Comment #6 from bkoz at gcc dot gnu dot org  2005-11-04 17:41 ---

In general, we make no claims as to ABI compliance wrt development/trunk
versions. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072

[Bug libstdc++/21072] base allocator change shared object issues

[matz at suse dot de]

--- Comment #5 from matz at suse dot de  2005-11-04 14:45 ---
While 4.0 had this fixed, trunk still uses the 'mt' allocator by default
on linux, and hence is incompatible with 3.4 and 4.0 by default.  Is that
really intended, or shouldn't also trunk default back to the 'new' allocator?


-- 

matz at suse dot de changed:

   What|Removed |Added

 CC||matz at suse dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072

[Bug libstdc++/21072] base allocator change shared object issues

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-17 18:27 
---
Ick! :(

Actually, I clearly remember a message from Mark warning that something could go
wrong when using different allocators in different sources, but then forgot
about the issue when we switched. I really hope that we can work around it, 
somehow...

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072

[Bug libstdc++/21072] base allocator change shared object issues

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2005-04-17 17:59 
---

Additional fixes include adding _M_reclaim_block checks. However, this seems to
be patching the symptom, not the disease.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072

[Bug libstdc++/21072] base allocator change shared object issues

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2005-04-17 17:57 
---
Created an attachment (id=8667)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8667&action=view)
revert base allocator change


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072

[Bug libstdc++/21072] base allocator change shared object issues

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2005-04-17 17:56 
---
Created an attachment (id=8666)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8666&action=view)
bug


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072