From mboxrd@z Thu Jan  1 00:00:00 1970
From: ljrittle@gcc.gnu.org
To: bjornw@planetarion.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, ljrittle@gcc.gnu.org, nobody@gcc.gnu.org
Subject: Re: libstdc++/4219: stl_alloc using -D__USE_MALLOC fails
Date: Tue, 04 Sep 2001 14:02:00 -0000
Message-id: <20010904210227.14416.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-09/msg00090.html
List-Id: <gcc-prs.sourceware.org>

Synopsis: stl_alloc using -D__USE_MALLOC fails

Responsible-Changed-From-To: unassigned->ljrittle
Responsible-Changed-By: ljrittle
Responsible-Changed-When: Tue Sep  4 14:02:27 2001
Responsible-Changed-Why:
    Look like mine.
State-Changed-From-To: open->feedback
State-Changed-By: ljrittle
State-Changed-When: Tue Sep  4 14:02:27 2001
State-Changed-Why:
    BTW, I think it would be a good idea to make the
    change you spotted.
    
    Is there a reason why you can't follow this advice on
    the new way to use the malloc interface in your application
    (from ./include/bits/c++config but see the primary
    documentation on the matter as well):
    
    // Default to the typically high-speed, pool-based allocator (as
    // libstdc++-v2) instead of the malloc-based allocator (libstdc++-v3
    // snapshots).  See libstdc++-v3/docs/html/17_intro/howto.html for
    // details on why you don't want to override this setting.  Ensure
    // that threads are properly configured on your platform before
    // assigning blame to the STL container-memory allocator.  After doing
    // so, please report any possible issues to libstdc++@gcc.gnu.org .
    // Do not blindly #define __USE_MALLOC here or on the command line.
    
    The problem with users defining __USE_MALLOC on the command
    line is that it is a subtle ABI change that may cause you
    problems...

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4219&database=gcc