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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=DcVUHTx3yDuuza2mu0YFMg8Qs8IrxN7nwd9Z6Uw0tOAfj4+R5ca31
	dlKR6BOAfrz0PgohgQAO03WpWGPep7ScVOVm2+ub7VB2A4N/LmIhFXRAsZg4An1G
	p3cDeYRXHJO9yiAO2JD3o7IyU+cHqRUpbkr1THOmpO5rG3MdIk6BBs=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=yrlYBxNQadok4VsfWxuW6170yOY=; b=htsr3NnsklROxX6IvJ3yRaU7L8Vj
	60dvat6sVKIrBzGkwjyNmAW6WS6hAaWLjyJtvlj2mH8du2+WRv1FdAGU+jCuZ89Z
	ijavmrNFhVIxZiHcSvzas0DPMTGO+8q+T6C1aFWraGGe1REP7mSgMcXFxUBQ0k/D
	tvXThrCfopEDHBE=
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=-4.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO: calimero.vinschen.de
Date: Thu, 9 Apr 2015 19:24:53 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: static vs. shared linking
Message-ID: <20150409172453.GB6901@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD"
Content-Disposition: inline
In-Reply-To: <5526351D.2000307@tiscali.co.uk>
User-Agent: Mutt/1.5.23 (2014-03-12)

--EuxKj2iCbKjpUGkD
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Apr  9 09:15, David Stacey wrote:
> On 31/03/2015 17:35, David Stacey wrote:
> >I'll post back here if and when I make more progress.
>=20
> 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 compili=
ng
> with '-frepo'. I do wonder if g++ should have resolved this automatically,
> as it does on Linux.
>=20
> Longer version: Finally, I think I understand what's going on.
> std::basic_string<> contains a static array of bytes that represent an em=
pty
> 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 arr=
ay
> and acts accordingly.
>=20
> There is supposed to be exactly one of these byte arrays for each
> instantiation of std::basic_string<>. However, in my example code (and al=
so
> 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<> c=
ode
> tried to 'delete' and area of memory that was never 'new'ed. Bang!
>=20
> Reading the gcc documentation [2], it appears that on Linux the compiler
> resolves this automatically by following the 'Borland' model, but on Cygw=
in
> it does not. Is this a gcc issue - should we expect g++ on Cygwin to beha=
ve
> as per Linux here?

The documentation just claims that the Borland mode is supported on
ELF and Windows systems, it does not state what's the default behaviour
is in terms of -frepo.

It would sure be nice if Cygwin's g++ behaves the same as the Linux g++,
so if the Linux g++ sets -frepo automatically, we should do the same.

> The solution is to compile with '-frepo', which works for both my test co=
de
> 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?

Sorry, I'm not an expert on this template stuff.  But if -frepo works
for you it sounds like the right thing to go forward.

> I can't believe that I'm the first person to fall foul of this - any libr=
ary
> 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'...
>=20
> 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.

Nice.


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--EuxKj2iCbKjpUGkD
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVJrXlAAoJEPU2Bp2uRE+gvlQP/0YyDUomlBYkDu9HmzE52Yv5
yOfo+zouFR8l6zKTqMWtRJO5vIcxWTeov9J7bG7MFCIdTPOFXPwDPEsPHXsl+93/
72qANqW7W8jd64wmmZ56eSoRlGZaGhB4hSHWWCuXDppxPCaPVZExwN6L/RbXtXSr
wrcwrbmIiKGBPHaamd9+pM7k9yQDhjJwDgu5qu+L2lzHnK2p3niPv5TD7uY/rS0x
BTU/sbJlAZrWMRdrxOy5QN19ygvyLDAtga4PiAKQ9WcNxLTkHVIsLf5+R9azJOEr
ZDpDMRJFrSPjFMe1glLQX+lIYfyPkeRKFxD20UyCcIjeN4Rwq/NKdF5gqPu0v0MS
pXa4e5m4QA2GxUQTM99BmDOwsguMLSuJeLXp2gM30GsMvPZLQv6HEW6nSfYbcKYX
xczzEKnZ1oBoIxCcqUqRYAwBwzSfgqNvhztyoN44kl9HqkQ0/2EwsE9Qq+fFcKux
8AVVgiB6Kt31JAuoC2K4g78TPhjvzB4gzYKCnjEQmv93ditkwRZuk7nXrguhU1ua
uVXfqyRA633Nx+Z5KQSA7wjAGHJR04tkS/3ZetN8ZEIZAMX4frep+cqMiloX3TZS
fGuMWiK3FyzEYsDy37UPjZQwlbOWtghtEDuEnGhZUPue/T6G99FsksEuPRolX5lE
w4wE/upO4EUIvnx9b3i+
=is0x
-----END PGP SIGNATURE-----

--EuxKj2iCbKjpUGkD--