This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: LoadLibrary error 487 (was Re: Please test latest developer snapshot)
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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat