Jan Nieuwenhuizen wrote: > libguile does not use C++. As far as I understand, it is a problem that > is introduced while linking the dlls.
The problem addressed by PR24196 and --enable-fully-dynamic-string is entirely centered around an implementation detail of std::string in libstdc++. Specifically, libstdc++ has an optimization where empty std::string objects don't get any memory allocated to them; their internal storage pointers are instead set equal to a reference to some static _S_empty_rep_storage object. This allows them to be created efficiently as well as allowing comparing for equality with other empty strings trivially and efficiently. This works great when libstdc++ is a shared library as this ensures that there will only be one instance of _S_empty_rep_storage for the entire process, so libstdc++ can always recognise an empty std::string by comparing its pointer to the address of _S_empty_rep_storage. However Cygwin has never had the luxury of shared gcc target libraries so every module that links with libstdc++ does so statically. If you have a process consisting of an .exe and a .dll which are both linked to libstdc++, both modules will each have their own instance of _S_empty_rep_storage. If a function in one module tries to pass an empty std::string argument to a function in the other, there will be a crash because that module will not see that this object is an empty string because its pointer does not point to that module's version of _S_empty_rep_storage. It will see it as a regular, fully initialized string when in fact it is not. The fix is to simply pessimize this optimization by initializing empty std::objects with their own storage instead of relying on having a global singleton. The issue should have no effect on code that does not pass std::string objects across DLLs, and by extension it should have no effect on C. It has nothing to do with DLLs in general or linking, and I'm struggling more and more to see how it would be relevant in this case. However, I have in fact verified myself that rebuilding libguile with Cygwin gcc 3.4.4 with the PR24196 patch does fix the problem. I'm now wonderding if PR24196 is a red herring and the real issue is an ABI incompatibility between 3.4 and 4.1. To verify this hypothesis, I will try rebuilding libguile with the older version of Cygwin gcc 3.4.4 without the PR24196 patch. Brian
