static vs. shared linking
Corinna Vinschen
corinna-cygwin@cygwin.com
Thu Apr 9 17:24:00 GMT 2015
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150409/94145880/attachment.sig>
More information about the Cygwin
mailing list