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. > > 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 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 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? 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 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. Nice. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpeegL3Sz05a.pgp
Description: PGP signature
