Re: PING Jan Nieuwenhuizen re libguile17

[Brian Dessent <brian@dessent.net>]

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