This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: static vs. shared linking
- From: David Stacey <drstacey at tiscali dot co dot uk>
- To: cygwin at cygwin dot com
- Date: Sat, 11 Apr 2015 20:21:14 +0100
- Subject: Re: static vs. shared linking
- Authentication-results: sourceware.org; auth=none
- References: <5510A9AB dot 7020607 at tiscali dot co dot uk> <5511AF73 dot 9070607 at tiscali dot co dot uk> <20150325090453 dot GB3017 at calimero dot vinschen dot de> <551339E4 dot 60705 at tiscali dot co dot uk> <20150330105529 dot GJ29875 at calimero dot vinschen dot de> <5519A0E1 dot 6020707 at tiscali dot co dot uk> <20150331090527 dot GB32403 at calimero dot vinschen dot de> <551ACCE2 dot 3000103 at tiscali dot co dot uk> <5526351D dot 2000307 at tiscali dot co dot uk> <5526EFDE dot 4090901 at cygwin dot com>
On 09/04/15 22:32, Larry Hall (Cygwin) wrote:
On 04/09/2015 04:15 AM, David Stacey wrote:
<snip>
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.
<snip>
It's true that someone using STL strings has the potential to see this
bug
but I doubt there are allot of template libraries out there pulling
the same
memory trick or doing so with the same catastrophic results.
It's going to affect all templates that have a static member variable,
where an instantiation of said template is passed across a DLL boundary.
Maybe there aren't too many of those.
In addition,
this is not the first time this has come up as an issue (for Cygwin or
other
platforms) in one form or another. Here's a good reference:
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612>
Wow - that was an interesting read, thank you! Obviously a different
context, but most definitely the same problem. It looks as though I
stumbled into a bear trap that's been around for at least ten years.
There they recommend the "--enable-fully-dynamic-string" flag as a
solution
for this particular problem but I agree if the "-frepo" will solve
this as
well, it's better because it manages templates better overall and aligns
with Linux behavior.
I'm not sure I like '--enable-fully-dynamic-string', because it changes
the API of std::string, and the two APIs are not interchangeable. So a
library compiled with '--enable-fully-dynamic-string' can't be used with
code that omitted that compiler option. You have to use it everywhere or
not at all.
Poco is a network-centric library for other programmes to use. If I were
to use '--enable-fully-dynamic-string' in compiling Poco then that would
force users of the Poco library to use that compiler option too. And if,
at the same time, they tried to link against another C++ API that wasn't
built that way then the code wouldn't link - or if it did link it would
crash when run.
So I either have to use '-frepo' or explicitly export the templates that
Poco uses. '-frepo' might take longer to compile, and I suspect that it
will force users of Poco to compile with '-frepo' as well. But it's
guaranteed to catch other templates that I might have missed, and it
will work with other C++ libraries that weren't built with
'--enable-fully-dynamic-string'. So I'll stick with '-frepo'.
Anyway, thanks again for the link - interesting stuff.
Dave.
--
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