From stdcxx-dev-return-5610-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Wed Oct 17 19:36:59 2007 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 65011 invoked from network); 17 Oct 2007 19:36:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Oct 2007 19:36:59 -0000 Received: (qmail 42350 invoked by uid 500); 17 Oct 2007 19:22:50 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 42339 invoked by uid 500); 17 Oct 2007 19:22:50 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 42327 invoked by uid 99); 17 Oct 2007 19:22:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2007 12:22:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2007 19:22:53 +0000 Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l9HJJVjG028320 for ; Wed, 17 Oct 2007 19:19:31 GMT Received: from [10.70.3.143] ([10.70.3.143]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 13:18:51 -0600 Message-ID: <47166072.80309@roguewave.com> Date: Wed, 17 Oct 2007 13:20:18 -0600 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: STDCXX-509 References: <47159353.1030509@roguewave.com> <471646AA.5080901@roguewave.com> <47165410.4040006@roguewave.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2007 19:18:51.0255 (UTC) FILETIME=[8CED4870:01C810F2] X-Virus-Checked: Checked by ClamAV on apache.org Travis Vitek wrote: >> From: Martin Sebor [mailto:sebor@roguewave.com] >> >> No, you've got it backwards. :) NO_BAD_CAST_ASSIGNMENT means >> the function is not found in the runtime and that we need to >> define it in the library. When the macro is not defined >> (notice the double negative, !NO_XXX), the function will not >> be defined. >> > > Yes. Thank you. Apparently I screwed my head on sideways this morning. > >>> The 4.2.0 library >>> does have the macro defined, so the symbol omitted from the library. >> The other way around. > > Ah-ha. Nope. Being that my head was screwed on backward, I went back and > re-checked my previous e-mail on the config macro defines. I was > backward there also. Okay, so you reached the right conclusion the first time, just based on the wrong interpretation of the wrong data. That's actually pretty amusing, despite the gravity of the problem. > > > The 4.1.3 config header has... > > #define _RWSTD_NO_BAD_CAST_ASSIGNMENT > #define _RWSTD_NO_BAD_CAST_COPY_CTOR > #define _RWSTD_NO_BAD_CAST_DEFAULT_CTOR > #define _RWSTD_NO_BAD_CAST_DTOR > #define _RWSTD_NO_BAD_CAST_WHAT > > #define _RWSTD_NO_BAD_TYPEID_ASSIGNMENT > #define _RWSTD_NO_BAD_TYPEID_COPY_CTOR > #define _RWSTD_NO_BAD_TYPEID_DEFAULT_CTOR > #define _RWSTD_NO_BAD_TYPEID_DTOR > #define _RWSTD_NO_BAD_TYPEID_WHAT > > #define _RWSTD_NO_EXCEPTION_ASSIGNMENT > #define _RWSTD_NO_EXCEPTION_COPY_CTOR > #define _RWSTD_NO_EXCEPTION_DEFAULT_CTOR > #define _RWSTD_NO_EXCEPTION_DTOR > #define _RWSTD_NO_EXCEPTION_WHAT > > The 4.2.0 config.h header has the following defines > > // #define _RWSTD_NO_BAD_CAST_ASSIGNMENT > // #define _RWSTD_NO_BAD_CAST_COPY_CTOR > #define _RWSTD_NO_BAD_CAST_DEFAULT_CTOR > // #define _RWSTD_NO_BAD_CAST_DTOR > #define _RWSTD_NO_BAD_CAST_WHAT > > // #define _RWSTD_NO_BAD_TYPEID_ASSIGNMENT > // #define _RWSTD_NO_BAD_TYPEID_COPY_CTOR > #define _RWSTD_NO_BAD_TYPEID_DEFAULT_CTOR > // #define _RWSTD_NO_BAD_TYPEID_DTOR > #define _RWSTD_NO_BAD_TYPEID_WHAT > > // #define _RWSTD_NO_EXCEPTION_ASSIGNMENT > // #define _RWSTD_NO_EXCEPTION_COPY_CTOR > // #define _RWSTD_NO_EXCEPTION_DEFAULT_CTOR > // #define _RWSTD_NO_EXCEPTION_DTOR > // #define _RWSTD_NO_EXCEPTION_WHAT > > So, the 4.1.3 library config figures that the mentioned symbols are not > in the runtime library, so they are built into the stdlib12d.dll for > 4.1.3. The 4.2.0 config is 'smarter' and discovers that some of the > symbols are provided, and omits them. This is consistent with the dump > of the libraries using 'dumpbin /exports'. But why is this a problem if the symbols are provided in the Visual Studio runtime library? Or did you mean "provided by the compiler unless we declare them" or something like that? Martin