LoadLibrary error 487 (was Re: Please test latest developer snapshot)

Corinna Vinschen corinna-cygwin@cygwin.com
Sat Feb 26 18:43:00 GMT 2011

On Feb 26 13:23, Christopher Faylor wrote:
> On Sat, Feb 26, 2011 at 01:14:33PM -0500, Christopher Faylor wrote:
> >On Sat, Feb 26, 2011 at 07:04:27PM +0100, Corinna Vinschen wrote:
> >>On Feb 26 16:32, Corinna Vinschen wrote:
> >>Chris, what do you think?  Is that something we should try?  Maybe we
> >>should try this only if we set a flag in some not yet existing
> >>LoadDLLfuncEx4?
> >
> >I think I'd be ok with the change if you made that:
> >
> >if (err == ERROR_INVALID_ADDRESS && in_forkee)
> >
> >It's still not foolproof but at least we wouldn't be affecting non-forked
> >processes and, in theory, the data segments of loaded dlls would be properly
> >filled out in a fork().
> >
> >In fact, hmm.  I wonder if you could just change std_dll_init so that it
> >always used DONT_RESOLVE_DLL_REFERENCES when in_forkee.  That might speed
> >fork up a little.
> >
> >This also assumes that Cygwin got in first to load the dll and that it's
> >being loaded during fork startup but I think that is a given, right?
> >
> >(Of course Microsoft says not to use this flag so I wonder if it will be
> >gone or broken in Windows 8)
> The other thing we could do is add a flag to thd dll_info struct which says
> "Use DONT_RESOLVE_DLL_REFERENCES" either in the forkee or always depending
> on what works for winm.dll.

That's what I meant above.  It would require a new LoadDLLfuncEx4,
wouldn't it?  OTOH, LoadDLLfuncEx3 is only referred to via the
definition of LoadDLLfuncEx2, so it should be simple to redefine.


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