John E. / TDM wrote:
> I would be ecstatic if an upcoming official release had some form of fix
> that allows exceptions to propagate out of DLLs without requiring shared
> versions of libgcc and libstdc++ (this is what ehstatic.patch does in
> TDM-GCC). However, I don't recall any other MinGW developers expressing
> support for this.
To reiterate the reasons for the lack of support for that patch (which
is not to say "opposition", just lack of explicit support):
1. It originated with Danny back in the 3.x days, and during the
3.x->4.0 transition he said:
On 4/20/2006 at 2:49 PM, Danny wrote:
> On 4/20/2006 at 11:23 AM, Chuck wrote:
>> Do you have a forward port [ed: to gcc-4.x] of your latest
>> patch (e.g. the 3.4.5-based one referred to in this
>> http://lists.zerezo.com/mingw-users/msg02554.html message,
>> that implements
>> (1) Extend the global shared_ptr stucture to handle the
> Yes. Against trunk pre-Christmas [ed: 12/2006]. But. I've finally
> convinced myself that the patch is more trouble than its worth.
> Libstdc++/libgcc as dll's is how I work it in my own trre. So you are
> on your own.
2. By extending the shared_ptr structure, you break the ABI. This means
that objects (*) compiled with current mingw can't/shouldn't be used
together with objects compiled with a gcc that incorporates this patch.
(*) Dunno if this "prohibition" is only for C++/Java, or for all
languages. Similarly, dunno if the "prohibition" is a hard one -- never
do X or you'll die in interesting ways; or a soft one -- well, you can
try it, and it might work. Or it might not, YMMV. And even if it works
for everything you try today, it might break for someone, on something
3. There was a brief effort during Google SoC when Aaron was attempting
to address this issue via another mechanism, for gcc-4.x. However, it
was never completed, and the "later subproject" never materialized:
"1. Exceptions across DLLs -- Item (3 libgcc_s) resolves this partially;
a later subproject will extend this to non-libgcc_s cases as discussed
with KT and VR"
[ed: anybody know who "KT" and "VR" are?]
In any case, I think the existence of this effort delayed any realistic
consideration of adopting the "Danny/TDM" patch officially (by
mingw.org; it's got no chance of going upstream to gcc).
Maybe it's time to reconsider that, but my fear is the following: that
incorporating this ABI-busting patch will ghettoize mingw-gcc-4.x, just
like the Danny-patch did to mingw/cygwin-gcc-3.x. If you want to know
why cygwin and mingw were so slooooooooooow to move to gcc-4.x, that
patch -- and lack of a similar version in the upstream ongoing gcc
development -- is a major reason why.
(Which is not to be critical of Danny or John E. at all. Without that
patch or something like it, gcc-3.x would have been unusable on
cygwin/mingw. This is because "the right solution" -- using shared
libgcc -- was not possible back then since the /other build tools/ like
auto*, libtool, and ld weren't capable of building libgcc as a DLL on