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.
Shall I write up a patch and submit it?
Thanks & Regards,
..mark
--
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
