This is the mail archive of the
mailing list for the Cygwin project.
Re: static vs. shared linking
- From: David Stacey <drstacey at tiscali dot co dot uk>
- To: cygwin at cygwin dot com
- Date: Thu, 09 Apr 2015 09:15:25 +0100
- Subject: Re: static vs. shared linking
- Authentication-results: sourceware.org; auth=none
- 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>
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 . 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 , 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.
 - /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/bits/basic_string.h
line 178, member '_S_empty_rep_storage'.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple