From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59987 invoked by alias); 9 Apr 2015 17:24:58 -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 59978 invoked by uid 89); 9 Apr 2015 17:24:57 -0000 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 Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Apr 2015 17:24:56 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 05FDBA80A3F; Thu, 9 Apr 2015 19:24:54 +0200 (CEST) Date: Thu, 09 Apr 2015 17:24:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: static vs. shared linking Message-ID: <20150409172453.GB6901@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com 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> <5526351D.2000307@tiscali.co.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) X-SW-Source: 2015-04/txt/msg00141.txt.bz2 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3072 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 Content-length: 819 -----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--