Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Tim Walkenhorst <tim.walkenhorst@in...> - 2005-04-18 10:23:08
I'm building an application with several DLLs and I make heavy use of
the C++ standard library (containers, streams...). I'm using the current
(3.4.2) version of MINGW in the binary distribution.
It seems that severe memory leaks occur whenever I write to a single
stringstream object from several DLLs. I guess the problem is that
memory is allocated within one DLL and freed within another.
This seems to be a well known problem, but I have not yet been able to
solve it on my own, although I've already spend a considerable amount of
time on it.
Previous posts on this list suggest that linking libstdc++ as DLL might
help. I've tried to do this using 'ar' to extract the object files from the
static archive and then relinking. Unfortunately linking against this
libstdc++ DLL causes my programs to crash, as soon as a throw
statement becomes reachable. (I don't have to actually throw, the
program crashes upon initialization.) In another attempt I tried to
make DLLs of libstdc++ and libgcc. Unfortunately I can't really
link libgcc on my own.
There are also legal problems rumored to exist when linking
against libstdc++ or libgcc DLLs. To be honest I can not image
why the way an application is linked should have any legal
Can anyone here give me an idea what the current situation with
libstdc++ and libgcc is and how my problems are best solved
at present? A step by step guide on how to make the two
DLLs mentioned above would also be appreciated.
From: Tim Walkenhorst <tim.walkenhorst@in...> - 2005-04-25 14:41:52
> It seems that severe memory leaks occur whenever I write to a single
> stringstream object from several DLLs. I guess the problem is that
> memory is allocated within one DLL and freed within another.
Just to avoid confusion: My problem didn't stem from these issues.
It was due to an old version of msvcrt.dll (version 6.1.8293.0) on
Windows NT (version 4.00.1381).
With this old DLL the following simple program displays a severe
s << 0.5;
Btw: I am still interested in linking libgcc and libstd++ as DLLs.