On Thu, 31 Jul 2025, Corinna Vinschen wrote: > > > > The sticking point would be libstdc++-6.dll once it is rebuilt with > > > > the additional --wrap arguments in GCC, because it would define all > > > > the operators and thus be incompatbile with older dll versions. > > ....and the new libstdc++-6.dll, we're fine. You wrote that the current > libstdc++-6.dll already uses the newer new/delete calls, right? Looks > like this works with old DLLs except overloading the operators will have > no result because these operators are unused in libstdc++-6.dll? > > I do hope I got that right...
I'm not sure it uses them, but if it does it would not work with overloading the operators because they are not wrapped yet. > > > > Well, the SO version of the new libstdc++ would have to be bumped to 7, > > > i. e., libstdc++-7.dll, that would solve half the problem. > > > > I hope not. The SO version of libstdc++ is 6 everywhere, and has been for > > some time. It's ABI hasn't changed. > > Yeah, but the DLL version number doesn't *have* to be the same as the ABI > of the DLL. If there's a good reason to bump, we can do that and IIRC > (but fuzzy), it wouldn't be the first time. > > Oh, wait! It just occured to me... > > We know that old DLLs don't write a value into __cygwin_user_data.api_major > and __cygwin_user_data.api_minor. > > But what if the new Cygwin DLL does just that? > > Assuming dll_crt0_0 (definitely called prior to _cygwin_crt0_common) > writes the current DLL CYGWIN_VERSION_API_MAJOR and > CYGWIN_VERSION_API_MINOR values into __cygwin_user_data.api_major/minor. > > Then _cygwin_crt0_common could check this before api_major/minor are > overwritten with the app version, and then use this info when > performing the CONDITIONALLY_OVERRIDEs. > + if (newu) > + new_dll_with_additional_operators = newu->api_major != 0 > + || newu->api_minor != 0; > + I'm considering 3 cases for _cygwin_crt0_common here, order in which they happen 1) running from a linked dll's startup (ie, libstdc++-6.dll) newu would contain values initialized from cygwin dll's startup, would write its api versions to static struct per_process in cygwin_attach_dll, OK 2) running from exe's startup newu would still contain values initialized from cygwin dll's startup, would write it's api versions to newu due to assignment of u = newu. OK for now 3) running from dynamically loaded DLL's startup newu would contain values from exe's startup, not zero, so would always write the new pointers to cxx_malloc, memory corruption.
