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 09/04/15 22:32, Larry Hall (Cygwin) wrote:
On 04/09/2015 04:15 AM, David Stacey wrote:


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.


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:


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.


Problem reports:
Unsubscribe info:

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