From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127684 invoked by alias); 9 Apr 2015 08:15:31 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 127660 invoked by uid 89); 9 Apr 2015 08:15:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_COUK,SPF_PASS autolearn=no version=3.3.2 X-HELO: out.ipsmtp4nec.opaltelecom.net Received: from out.ipsmtp4nec.opaltelecom.net (HELO out.ipsmtp4nec.opaltelecom.net) (62.24.202.76) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Thu, 09 Apr 2015 08:15:28 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CXAQAMNCZV/4BQ0lUNT4NaXIMVwwuFdgMCAoICAQEBAQEBhR4BAQQjFUARCxgCAgUWCwICCQMCAQIBNw4TCAEBF4gctRRwlkcBAQEBAQUBAQEBAQEBFwSBIYoKgmaBTVAWglKBRQWOZ4YLhzCPfYNLgiIfgVFuAQEBgQCBQAEBAQ X-IPAS-Result: A2CXAQAMNCZV/4BQ0lUNT4NaXIMVwwuFdgMCAoICAQEBAQEBhR4BAQQjFUARCxgCAgUWCwICCQMCAQIBNw4TCAEBF4gctRRwlkcBAQEBAQUBAQEBAQEBFwSBIYoKgmaBTVAWglKBRQWOZ4YLhzCPfYNLgiIfgVFuAQEBgQCBQAEBAQ Received: from 85-210-80-128.dynamic.dsl.as9105.com (HELO [127.0.0.1]) ([85.210.80.128]) by out.ipsmtp4nec.opaltelecom.net with ESMTP; 09 Apr 2015 09:15:24 +0100 Message-ID: <5526351D.2000307@tiscali.co.uk> Date: Thu, 09 Apr 2015 08:15:00 -0000 From: David Stacey User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: static vs. shared linking References: <5510A9AB.7020607@tiscali.co.uk> <5511AF73.9070607@tiscali.co.uk> <20150325090453.GB3017@calimero.vinschen.de> <551339E4.60705@tiscali.co.uk> <20150330105529.GJ29875@calimero.vinschen.de> <5519A0E1.6020707@tiscali.co.uk> <20150331090527.GB32403@calimero.vinschen.de> <551ACCE2.3000103@tiscali.co.uk> In-Reply-To: <551ACCE2.3000103@tiscali.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00130.txt.bz2 On 31/03/2015 17:35, David Stacey wrote: > I'll post back here if and when I make more progress. tl;dr: The problem was caused by a template being instantiated twice (one in the shared DLL and one in the main executable). This was fixed by compiling with '-frepo'. I do wonder if g++ should have resolved this automatically, as it does on Linux. Longer version: Finally, I think I understand what's going on. std::basic_string<> contains a static array of bytes that represent an empty string [1]. If your string happens to be empty, the internals of std::basic_string<> point at this byte array rather than dynamically creating storage. At various points in the std::basic_string<> code, it tests to see if the address of the internal storage matches this byte array and acts accordingly. There is supposed to be exactly one of these byte arrays for each instantiation of std::basic_string<>. However, in my example code (and also poco-1.6.0) there were two - one in the shared DLL and one in the main executable. Hence testing the pointer failed (the internal storage was pointing at the 'wrong' static byte array), and the std::basic_string<> code tried to 'delete' and area of memory that was never 'new'ed. Bang! Reading the gcc documentation [2], it appears that on Linux the compiler resolves this automatically by following the 'Borland' model, but on Cygwin it does not. Is this a gcc issue - should we expect g++ on Cygwin to behave as per Linux here? The solution is to compile with '-frepo', which works for both my test code and also poco-1.6.0 - although it has quite an impact on the compilation time (it trebles what was already a fairly lengthy compilation). Do you think this is the correct way to proceed, or should I look to explicitly export an instantiation of the std::basic_string<>s that Poco creates? I can't believe that I'm the first person to fall foul of this - any library that relies heavily on templates risks falling into the same trap. For instance, how is this issue resolved in Boost? I've looked at 'boost.cygport' and it isn't using '-frepo'... Finally, many thanks to all those who have taken the time to help resolve this matter - you've (just about) managed to keep me sane! I have one more failing test to investigate, but hopefully I can get poco-1.6.0 released soon. Dave. [1] - /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/bits/basic_string.h line 178, member '_S_empty_rep_storage'. [2] - https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Template-Instantiation.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple