Re: static vs. shared linking

[David Stacey <drstacey@tiscali.co.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 [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