From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17988 invoked by alias); 13 May 2002 20:20:31 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 17965 invoked by uid 61); 13 May 2002 20:20:30 -0000 Date: Mon, 13 May 2002 13:20:00 -0000 Message-ID: <20020513202030.17964.qmail@sources.redhat.com> To: Sylvain.Pion@sophia.inria.fr, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, ljrittle@gcc.gnu.org, nobody@gcc.gnu.org From: ljrittle@gcc.gnu.org Reply-To: ljrittle@gcc.gnu.org, Sylvain.Pion@sophia.inria.fr, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, ljrittle@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/6641: -D__USE_MALLOC doesn't link X-SW-Source: 2002-05/txt/msg00364.txt.bz2 List-Id: Synopsis: -D__USE_MALLOC doesn't link Responsible-Changed-From-To: unassigned->ljrittle Responsible-Changed-By: ljrittle Responsible-Changed-When: Mon May 13 13:20:30 2002 Responsible-Changed-Why: My pet issue. State-Changed-From-To: open->closed State-Changed-By: ljrittle State-Changed-When: Mon May 13 13:20:30 2002 State-Changed-Why: You are correct in that this is a change from 2.95 and perhaps 3.0 (the only correct use of __USE_MALLOC was surely documented by the 3.0 release but it is possible that it still "worked"). The libstdc++-v3 documentation now explicitly says that you must rebuild the entire library to define library implementation macros such as __USE_MALLOC. The use of macros in the library implementation name space, such as __USE_MALLOC, which may change internal implementation can violate the one-definition rule of C++. A patch that correctly handles all one-definition issues with such a macro might be accepted. However, I will be holding my nose. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6641