On Mar 5 01:18, Mark Geisert wrote:
> Hi Corinna,
>
> Corinna Vinschen via Cygwin wrote:
> > On Mar 4 01:05, Mark Geisert wrote:
> > > Corinna Vinschen via Cygwin wrote:
> > > > Is there a way around that? I'm not quite sure, so let's brain storm
> > > > a bit, ok?
> > > >
> > > > - One thing we could try is to remove the above code, but add a python
> > > > hack to dlsym instead. This would let the "old" DLLs work again as
> > > > before and for python we could add a hack to dlsym, along these
> > > > lines:
> > > >
> > > > if (CYGWIN_VERSION_CHECK_FOR_UNAME_X
> > > > && modulehandle == cygwin1.dll
> > > > && strcmp (symname, "uname"))
> > > > symname = "uname_x";
> > > >
> > > > Thoughts? Other ideas?
> > >
> > > That's a sly fix, but it seems that it would do the job. That's good!
> > >
> > > On a different tack, I was thinking about how run time code could tell the
> [...somewhat of a dead-end tangent elided...]
> > However, it's not clear how this fixes the actual problem. We just
> > don't have a way to know what size the caller expects.
> >
> > Having version or size info in structs like the Win32 API does in a
> > couple of cases makes a lot more sense now...
>
> Indeed. I like your dlsym proposal, but I would code the "modulehandle ==
> cygwin1.dll" first as it's less likely to be true than the version check.
>
> I think "the above code" you mentioned still needs to be retained to deal
> with old exes calling uname directly and needing the old version.
To the contrary. That code was only required to deal with *new*
executables calling uname via the old entry point, because they called
dlopen/dlsym("uname"). Given this is handled in dlsym with my above
proposal, that addition in uname should go away. After all, it's the
reason for the DLL crashes we're talking about here.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
