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=p044aeK4BczASgxf+79odw5st1ikaIOIqk/dqcHKHFQ
	uOUJuTBW42fezvufuhr3eN2O9df7Mszo7yyPGCGy5R461D2DMutPrIom4OM8XdQH
	Pf1nD968wNJYpNiWW9h9vB53o6jdXeeGpfd+5wKjdCEIVM4J9oWNfGpX3uLl5ifQ
	=
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=jLFFwOL18GJsAIiakxDHZoSlILE=; b=mzyy8NMT1d5vISw+r
	iy9L7YHanQBj6HzTJRvqp4zjTURfred3kmCjEZOVYmWMmwgo90YXifvutJ9k7Q0f
	/xMsiFrm/01ql53GW8k4fQPC5+cvvBdoK/r++tedQz/Ufk3WxtFVYIi+Jpet2zRc
	hcZma3NSVefK2ejKlQVll8RQvk=
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=2.8 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_COUK,SPF_PASS autolearn=no version=3.3.2
X-HELO:	out.ipsmtp4nec.opaltelecom.net
X-SMTPAUTH:	drstacey AT tiscali DOT co DOT uk
X-IronPort-Anti-Spam-Filtered:	true
X-IronPort-Anti-Spam-Result:	A2CWAQCvcylV/4xZ0lUNT4NeXMY7hXwDAgKBfQEBAQEBAYUdAQEBAwE4QAYLCxgJFg8JAwIBAgFFEwgBAReIBxW1UZceAQEBAQYBAQEBAQEYBIsrhQMWhBcFjnKGE4czhhyNM4IlHIFRbgGCQgEBAQ
X-IPAS-Result:	A2CWAQCvcylV/4xZ0lUNT4NeXMY7hXwDAgKBfQEBAQEBAYUdAQEBAwE4QAYLCxgJFg8JAwIBAgFFEwgBAReIBxW1UZceAQEBAQYBAQEBAQEYBIsrhQMWhBcFjnKGE4czhhyNM4IlHIFRbgGCQgEBAQ
Message-ID:	<5529742A.7000902@tiscali.co.uk>
Date:	Sat, 11 Apr 2015 20:21:14 +0100
From:	David Stacey <drstacey AT tiscali DOT co DOT uk>
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; 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> <5526351D DOT 2000307 AT tiscali DOT co DOT uk> <5526EFDE DOT 4090901 AT cygwin DOT com>
In-Reply-To:	<5526EFDE.4090901@cygwin.com>
X-IsSubscribed:	yes

On 09/04/15 22:32, Larry Hall (Cygwin) wrote:
> On 04/09/2015 04:15 AM, David Stacey wrote:
>
> <snip>
>
>> 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.
>
> <snip>
>
> It's true that someone using STL strings has the potential to see this 
> bug
> but I doubt there are allot of template libraries out there pulling 
> the same
> memory trick or doing so with the same catastrophic results. 

It's going to affect all templates that have a static member variable, 
where an instantiation of said template is passed across a DLL boundary. 
Maybe there aren't too many of those.

> In addition,
> this is not the first time this has come up as an issue (for Cygwin or 
> other
> platforms) in one form or another.  Here's a good reference:
>
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612>

Wow - that was an interesting read, thank you! Obviously a different 
context, but most definitely the same problem. It looks as though I 
stumbled into a bear trap that's been around for at least ten years.

> There they recommend the "--enable-fully-dynamic-string" flag as a 
> solution
> for this particular problem but I agree if the "-frepo" will solve 
> this as
> well, it's better because it manages templates better overall and aligns
> with Linux behavior.

I'm not sure I like '--enable-fully-dynamic-string', because it changes 
the API of std::string, and the two APIs are not interchangeable. So a 
library compiled with '--enable-fully-dynamic-string' can't be used with 
code that omitted that compiler option. You have to use it everywhere or 
not at all.

Poco is a network-centric library for other programmes to use. If I were 
to use '--enable-fully-dynamic-string' in compiling Poco then that would 
force users of the Poco library to use that compiler option too. And if, 
at the same time, they tried to link against another C++ API that wasn't 
built that way then the code wouldn't link - or if it did link it would 
crash when run.

So I either have to use '-frepo' or explicitly export the templates that 
Poco uses. '-frepo' might take longer to compile, and I suspect that it 
will force users of Poco to compile with '-frepo' as well. But it's 
guaranteed to catch other templates that I might have missed, and it 
will work with other C++ libraries that weren't built with 
'--enable-fully-dynamic-string'. So I'll stick with '-frepo'.

Anyway, thanks again for the link - interesting stuff.

Dave.


--
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 -