Re: static vs. shared linking

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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

Attachment: pgpZ5O3qoPEUx.pgp
Description: PGP signature