This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [Fwd: dlopen regression in 1.7? (or is it just me?)]
On Wed, Aug 12, 2009 at 12:08:08PM -0400, Christopher Faylor wrote:
>On Wed, Aug 12, 2009 at 05:16:00PM +0200, Corinna Vinschen wrote:
>>On Aug 12 15:48, Dave Korn wrote:
>>> Corinna Vinschen wrote:
>>> > Of course, we could also kludge dlopen to workaround "broken" DLLs.
>>> > It could store the old cxx_malloc pointer before calling LoadLibrary and
>>> > restore it afterwards. This would allow us to stick with these DLLs.
>>> >
>>> > I tested the below patch to dlopen. It seems to work nicely for the
>>> > testcase sent by Peter. Any drawbacks?
>>>
>>> The only slight drawback is it means that you can't have a malloc override in
>>> a dlopen'd library, because it restores the pointer without copying back the
>>> updated set of overrides from the library's internal struct that the pointer now
>>> points at.
>>>
>>> Of course that's good because it means you can't dlclose it and suddenly have
>>> operator new disappear, but it might be a nice feature. To make it work, we'd
>>> need to maintain a stack of override entries, so that at dlclose time we could
>>> restore the previous set of overrides. I'm just pondering if we can figure out
>>
>>A stack wouldn't help since the dlclose calls can be in arbitrary order.
>
>Right, but couldn't you store/restore this in the per-dll structure?
Which is already a linked list, btw.
In case anyone cares.
cgf