[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] shared libstdc++ for mingw32

From: Greg Chicares
Subject: Re: [lmi] shared libstdc++ for mingw32
Date: Fri, 05 Aug 2005 21:05:22 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

On 2005-8-5 20:22 UTC, Vadim Zeitlin wrote:
> On Fri, 05 Aug 2005 17:35:20 +0000 Greg Chicares <address@hidden> wrote:
> GC> So cvs as of this instant works with msw only if wx is built
> GC> monolithically--a somewhat bizarre restriction that you're
> GC> trying to work around by building a shared libstdc++ .
>  I hope this is the only problem currently but I'm not sure. In general I'm
> very wary of using 2 different run-times inside the same process and here
> we have at least 3 of them (2 DLLs + the main exe). Not to be pessimistic,
> but I fully expect more trouble because of this in the future.

I hear you. Does it help at all if we build all three binary
files on the same machine, at the same time?

I wonder whether the problem stems from, or is exacerbated by,
the usual wx procedure of allocating objects on the exe's heap
and letting wx (a dll, here) deallocate them. Is there any
intention to use a RAII approach instead in wx version 3?

> GC> mailing-list messages posted by three of the
> GC> MinGW developers suggest that
> GC>  - they want to make libstdc++ a dll in the long term
>  Unfortunately the last mention of this (worthy) goal is from November
> 2004 so it doesn't seem to be very urgent. And doing it seems to imply
> patching libstdc++ sources on gcc HEAD which is not an obvious thing to do
> for a person external to the project (i.e. it's not obvious to get such
> patches accepted).

Danny is a gcc maintainer, so he has cvs write access, but I'm
sure he'd discuss changes with the libstdc++ maintainers first.

Anyway, it's been mentioned on the MinGW mailing list again today....

reply via email to

[Prev in Thread] Current Thread [Next in Thread]