On Mar 31 15:46, Corinna Vinschen wrote:
> On Mar 31 13:06, Corinna Vinschen wrote:
> > On Mar 31 17:18, Yuyi Wang wrote:
> > > > I tested this scenario, and this problem only occurs with
> > > > dlopening cygwin1.dll.
> > >
> > > Not only cygwin1.dll, but also native dlls, e.g., kernel32.dll or
On Mar 31 13:06, Corinna Vinschen wrote:
> On Mar 31 17:18, Yuyi Wang wrote:
> > > I tested this scenario, and this problem only occurs with
> > > dlopening cygwin1.dll.
> >
> > Not only cygwin1.dll, but also native dlls, e.g., kernel32.dll or
> > user32.dll.
> > I haven't tested the next release
On Mar 31 17:18, Yuyi Wang wrote:
> > I tested this scenario, and this problem only occurs with
> > dlopening cygwin1.dll.
>
> Not only cygwin1.dll, but also native dlls, e.g., kernel32.dll or user32.dll.
> I haven't tested the next release, but do you think it's the same reason for
> win32 dlls?
> I tested this scenario, and this problem only occurs with
> dlopening cygwin1.dll.
Not only cygwin1.dll, but also native dlls, e.g., kernel32.dll or user32.dll.
I haven't tested the next release, but do you think it's the same reason for
win32 dlls?
Hi Yuri,
On Mar 30 23:00, Yuyi Wang wrote:
> dlclose tries to decrease the ref count of the dll* entry, but a new dll
> opened by dlopen doesn't create a new dll* entry.
> ---
> winsup/cygwin/dlfcn.cc | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/winsup/cygwin/dlf
