This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: static vs. shared linking

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.


[1] - /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/bits/basic_string.h line 178, member '_S_empty_rep_storage'. [2] -

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]