From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13361 invoked by alias); 24 Nov 2006 19:01:56 -0000 Received: (qmail 13353 invoked by uid 22791); 24 Nov 2006 19:01:55 -0000 X-Spam-Check-By: sourceware.org Received: from exprod6og53.obsmtp.com (HELO exprod6og53.obsmtp.com) (64.18.1.187) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 24 Nov 2006 19:01:46 +0000 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Fri, 24 Nov 2006 11:01:44 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id kAOIx0vV013383 for ; Fri, 24 Nov 2006 10:59:00 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id kAOJ1iPF023872 for ; Fri, 24 Nov 2006 11:01:44 -0800 (PST) Received: from namailgen.corp.adobe.com ([10.8.192.91]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Nov 2006 11:01:44 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: typeinfo problem (bug?) Date: Fri, 24 Nov 2006 19:01:00 -0000 Message-ID: From: "John \(Eljay\) Love-Jensen" To: "MSX to GCC" X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2006-11/txt/msg00294.txt.bz2 Hi everyone, I've run into a problem with std::type_info. It appears that hidden visibility can cause multiple instances of a type_in= fo object for one type, hence RTTI information is not being merged across S= SO and DSO boundaries. :-( Is there an appropriate flag to specify to the compiler that will cause __G= XX_MERGED_TYPEINFO_NAMES to be defined as 1? I supposed I can just -D__GXX_MERGED_TYPEINFO_NAMES ... but I was under the= impression that the __GXX_WHATEVER preprocessor defines shouldn't be twidd= led by hand. Perhaps I'm mistaken about refraining from specifying -D__GXX_WHATEVER on t= he g++ command line? - - - - - - - - - - - - - - - - - - - - - Also (incidentally & unrelated to the above), it is very weird that __GXX_M= ERGED_TYPEINFO_NAMES has two different semantics. Specifying __GXX_MERGED_= TYPEINFO_NAMES has two unrelated orthogonal effects: 1. are the before() and operator=3D=3D() routines inline or function calls 2. are the before() and operator=3D=3D() routines lightweight pointer compa= res or slightly more costly string compares I'd like to have inline routines using __builtin_strcmp. But I can imagine= some situations where __builtin_strcmp is desired, but only as function ca= lls and not inline. Unfortunately... __GXX_MERGED_TYPEINFO_NAMES =3D=3D 0 means "strcmp & function calls". __GXX_MERGED_TYPEINFO_NAMES =3D=3D 1 means "pointer compares & inline". There's no "strcmp & inline" (what I want), nor is there "pointer compares = & function calls". Hmmmm. I'm using GCC 4.0.1, so perhaps this has been fixed by now. Sincerely, --Eljay