From stdcxx-dev-return-6397-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Fri Dec 07 18:56:29 2007 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 20750 invoked from network); 7 Dec 2007 18:56:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Dec 2007 18:56:29 -0000 Received: (qmail 38525 invoked by uid 500); 7 Dec 2007 18:56:17 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 38509 invoked by uid 500); 7 Dec 2007 18:56:17 -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 38498 invoked by uid 99); 7 Dec 2007 18:56:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Dec 2007 10:56:17 -0800 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: domain of msebor@gmail.com designates 209.85.146.183 as permitted sender) Received: from [209.85.146.183] (HELO wa-out-1112.google.com) (209.85.146.183) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Dec 2007 18:55:56 +0000 Received: by wa-out-1112.google.com with SMTP id n4so4688623wag for ; Fri, 07 Dec 2007 10:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; bh=lC1ZlPnaoVqSOGgYILBSK3/LIqk2rwo0Pz1U1OtLlE4=; b=RFLkzsEQmzGEZKenngdk6j1jzcf/NXzOEFMitBKEW7Jq24ZAtRlYsmUV/yBBFYvBIhpI9GoU/DQKYalaRgCvxZKWBF70DHSnXnUDNdxzEGGCTK6nSIch28kfutx/RtwekzX/1S2NDjj8q864K7DeoPizU3dYsOOS94uMpqOoSdY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=lIriwC0A949MpM0IQN3qMz9tMMnTf71esZ+3Dty11XYXpk3J9adc6IRl8J34oRLUZTfsZvs1qz2R4eF29gnPB1WPz4bQ8dKVORnUqWlbpiyiGUjRklqMEynrPPIMR/rYZvppcjLh7B1ZpUkKtmEb88ekBRAaywWn+B+loj6eFbI= Received: by 10.115.95.1 with SMTP id x1mr3448121wal.1197053758749; Fri, 07 Dec 2007 10:55:58 -0800 (PST) Received: from bugsy.sebor.net ( [71.229.200.170]) by mx.google.com with ESMTPS id f20sm1432069waf.2007.12.07.10.55.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Dec 2007 10:55:57 -0800 (PST) Message-ID: <4759973B.5060602@roguewave.com> Date: Fri, 07 Dec 2007 11:55:55 -0700 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] STDCXX-507 (or using __declspec(dllexport/dllimport on gcc/cygwin in shared builds) References: <7BDB2168BEAEF14C98F1901FD2DE643801511BE7@epmsa009.minsk.epam.com> In-Reply-To: <7BDB2168BEAEF14C98F1901FD2DE643801511BE7@epmsa009.minsk.epam.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Martin Sebor X-Virus-Checked: Checked by ClamAV on apache.org Farid Zaripov wrote: > Today I've verified the patch for STDCXX-507 on gcc 4.2.0 and gcc > 3.4.4. I get really nervous whenever we start to mess around with the runtime symbols, especially when changing which ones are exported on Windows and which ones aren't. Doesn't exporting just members and not the whole class have an impact on things like RTTI and exceptions? Have you tested it with the other Windows compilers (Intel C++ and MSVC)? Also, I'm more than a little uncomfortable with hardcoding __CYGWIN__ all over the place. Isn't there a single file where we could tweak _RWSTD_NO_XXX_DEFAULT_CTOR et al macros? Finally, did you consider STDCXX-408 when enabling dllexport? Travis, as the other Windows expert, can you take a look at Farid's patch and let us know what you think? Thanks! Martin > > The patch is here: > https://issues.apache.org/jira/secure/attachment/12371246/cygwin.patch > > ChangeLog: > > STDCXX-507 > * include/rw/_defs.h [__CYGWIN__ && _RWSHARED]: #define _RWSTD_EXPORT > macro > using __declspec (dllexport) directiive. > * include/typeinfo (bad_cast): Don't declare class as _RWSTD_EXPORT. > Declare as _RWSTD_EXPORT the only members, that doesn't already > present in libc. > (bad_typeid): Ditto. > * include/exception (exception): Ditto. > (bad_exception): Ditto. > (set_unexpected): Ditto. > (unexpected): Ditto. > (set_terminate): Ditto. > (terminate): Ditto. > (uncaught_exception): Ditto. > * include/new (bad_alloc): Ditto. > * etc/config/gcc.config [CYGWIN] (SHARED_CPPFLAGS): #define _RWSHARED > for shared builds. > (LDSOFLAGS): turn on exporting of the all symbols (this feature is > disabled by default > due to using __declspec(dllexport)). > (LDFLAGS): Force ".exe" executable files extension. > > Without using of the -export-all-symbols linker option the some > examples and > tests are failed to link due to "undefined reference to the [typeinfo > for ...]". > Where ... is std::istream, std::ostream, std::wistream, std::wostream, > ... > I don't know why these typeinfo's are not exported and how to explicitly > export > them. Also the __rw_atomic_addxx() and __rw_atomic_xcghxx() functions > are not > exported because they are defined in assembly file (the gcc and ld > doesn't have > the feature like #pragma comment (linker, "/EXPORT=...") in MSVC). So > the > -export-all-symbols option is needed to deal with "undefined reference" > errors. > > The -force-exe-suffix option is not related to the issue. It's just > forces, that > all executable names will end's with ".exe". > > Farid. >