X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=QXMgHf5mi0hG2bLrMAmHo93m9JHIVQz/vIXauWChb00
	ELVYRENTDqH67RqMwfqt5sAXwwX+Z5yX2ZQcLzH8NmK+7SsyZ7PAxXtVkOcYwVnF
	fStvKsSoub6Rwq7oCPqG2Zk4GQRkL0c1paSm4ErRynF+T41FnT4tRmDg+PPGdm00
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=p4cWx90MfHK/9wca5Yu973x6peM=; b=qI9zZ7PDGCmd+QEUq
	g/UzW1c9LBBZvcqGRtGlTa6NA2OHigFvXCruS+DMBmq6KtzrDpmGttzzCNjMMwnp
	6m68t50B3noPP+OU7L9OIdLsVRsxTHMddUSOePrAhdpeM7jLO/27834qqn57KLbc
	gw+nAJ3C3NmSgjIZ5pNGbvOdPY=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
X-IronPort-Anti-Spam-Filtered:	true
X-IronPort-Anti-Spam-Result:	A2CXAQAMNCZV/4BQ0lUNT4NaXIMVwwuFdgMCAoICAQEBAQEBhR4BAQQjFUARCxgCAgUWCwICCQMCAQIBNw4TCAEBF4gctRRwlkcBAQEBAQUBAQEBAQEBFwSBIYoKgmaBTVAWglKBRQWOZ4YLhzCPfYNLgiIfgVFuAQEBgQCBQAEBAQ
X-IPAS-Result:	A2CXAQAMNCZV/4BQ0lUNT4NaXIMVwwuFdgMCAoICAQEBAQEBhR4BAQQjFUARCxgCAgUWCwICCQMCAQIBNw4TCAEBF4gctRRwlkcBAQEBAQUBAQEBAQEBFwSBIYoKgmaBTVAWglKBRQWOZ4YLhzCPfYNLgiIfgVFuAQEBgQCBQAEBAQ
Message-ID:	<5526351D.2000307@tiscali.co.uk>
Date:	Thu, 09 Apr 2015 09:15:25 +0100
From:	David Stacey <drstacey AT tiscali DOT co DOT uk>
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 AT cygwin DOT com
Subject:	Re: static vs. shared linking
References:	<5510A9AB DOT 7020607 AT tiscali DOT co DOT uk> <5511AF73 DOT 9070607 AT tiscali DOT co DOT uk> <20150325090453 DOT GB3017 AT calimero DOT vinschen DOT de> <551339E4 DOT 60705 AT tiscali DOT co DOT uk> <20150330105529 DOT GJ29875 AT calimero DOT vinschen DOT de> <5519A0E1 DOT 6020707 AT tiscali DOT co DOT uk> <20150331090527 DOT GB32403 AT calimero DOT vinschen DOT de> <551ACCE2 DOT 3000103 AT tiscali DOT co DOT uk>
In-Reply-To:	<551ACCE2.3000103@tiscali.co.uk>
X-IsSubscribed:	yes

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

- Raw text -