On Mar 4 18:05, Takashi Yano via Cygwin wrote: > Hi Corinna, > > On Wed, 3 Mar 2021 12:00:25 +0100 > Corinna Vinschen wrote: > > [Ping Mark Geisert] > > > > 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? > > It sounds very reasonable to me to deal with it within dlsym(), > as the problem arises from the use of dlsym(). However, what > happens if newly built .exe is linked to old dll which calls > uname() via dlsym()? I am not sure whether there are such dlls.
We simply can't fix that, because we don't have a Cygwin-specific per-DLL information block as we have for EXEs. There's no way to workaround that problem. 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
