On Jul 25 10:28, Jeremy Drake via Cygwin wrote: > On 2025年7月25日, Corinna Vinschen via Cygwin wrote: > > Nevertheless, the code overriding the members in per_process_cxx_malloc > > is living in the app (_cygwin_crt0_common.cc). If you just append members > > to per_process_cxx_malloc nad implement the wrappers in cxx.cc and > > libstdcxx_wrapper.cc, then old apps using the old _cygwin_crt0_common.cc > > will just not see the new functions. So that should work out of the > > box, shouldn't it? > > I missed a pointer dereference in _cygwin_crt0_common.cc that meant the > struct was being copied rather than the pointer replaced. I was concerned > that a pointer to the old struct might be used, and garbage found in the > new fields. I see now that it copies the contents, and if the struct is > smaller it will obviously leave the new fields alone. > > I came across this comment that concerned me though > /* Broken DLLs built against Cygwin versions 1.7.0-49 up to 1.7.0-57 > [...] > I don't see the save and restore mentioned in dlopen... Are these old > DLLs sufficiently old that there wasn't 64-bit yet, and therefore can't be > used anymore?
Indeed, the comment is a remnant from our 32 bit past. Cygwin 1.7.0 was from 2009, while we merged the 64 bit stuff into the tree in 2013 and the first official version supporting x86_64 was 1.7.19, I think. 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