[Fwd: dlopen regression in 1.7? (or is it just me?)]

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Aug 12 15:42:00 GMT 2009

On Aug 12 16:44, Dave Korn wrote:
> Corinna Vinschen wrote:
> > A stack wouldn't help since the dlclose calls can be in arbitrary order.
>   Sorry, wrong terminology.  I was thinking of a linked list really.  It would
> behave mostly like a stack, except in such cases.
> > And there's something else which speaks agains supporting overriding new
> > in dlopened libs.  Consider this scenario:
> > 
> >   dlopen(lib1)  Installs own new
> >   dlopen(lib3)  Installs own new
> > 
> > At this point the new of lib2 will be used for any further call.
> > But what if lib1 expects that *its* new is used?  
>   I don't think lib1 is allowed to expect that.  What if the user defined an
> operator new in their executable?  That takes priority over the lot, and even in
> static linking that's the case.  So I don't think it's legitimate to write
> library code that assumes a particular implementation of operator new is in effect.
> > Isn't the entire
> > idea to support dynamically overridable allocators quite dangerous?
>   Only about as dangerous as the idea to support statically overrideable
> allocators, I think.  And yes, ELF is full of this nutso stuff and things do
> dynamically appear and disappear at run time.  And I tend to feel that we don't
> want to go down that road.  So I think the simple solution of not permitting
> overrides in dynamically opened libraries is probably the right solution, too.
>   All I'm testing is a slightly tweaked version of your patches with a couple of
> comments added.  Do you want to go ahead and check them in, or shall I post the
> complete patch to the -patches list once I've given it a thorough test?  They
> look about right to me.

I will wait for your comment-extended version, no worries.

But I'm still not clear on

  newu->cxx_malloc = &__cygwin_cxx_malloc;


  *newu->cxx_malloc = __cygwin_cxx_malloc;

What's the better approach now?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list