Re: [MinGW-dvlpr] GCC 4.4.0: Naming conventions

[Aaron W. L. <aar...@aa...>]

Charles Wilson wrote:
> Aaron W. LaFramboise wrote:
>> Charles Wilson wrote:

> I thought the default EH mode for mingw gcc was going to be sjlj (and
> /because/ it was the default, it was to be named 'libgcc_s-1.dll' not
> 'libgcc_s_sjlj-1.dll'; only the non-default, dw2, runtime would include
> the decorator).  Is that incorrect?  I know that cygwin is jumping onto
> the dw2 bandwagon -- but the broken "callback" issue wrt dw2 was, I
> thought, a major issue for mingw. Was I wrong about this, too?

I believe FSF GCC generates a DLL decorator in both models now.  Maybe 
once we're really comfortable with Dwarf-2 and need an excuse to bump 
the ABI, we can use the unqualified name.

MinGW GCC will be using Dwarf-2 from here on out, as discussed 
previously on this list and mingw-users.

There is now special support for people who need to throw C++ language 
exceptions through Win32 API functions and other foreign frames.  This 
mechanism is a little rough, but hopefully community feedback from 
people who are actually doing this will help improve it.

FSF GCC uses SJLJ as the default for mingw32, but this doesn't really 
mean anything.  At some point, we'll submit a patch to switch the 
default to Dwarf-2.


>> unless one 
>> of these two conditions is met:
>>
>> 1) The program throws exceptions between DLLs, or
>> 2) The program throws exceptions and is multithreaded (*)
> 
> But how do I know this if I'm distributing a DLL?

You're right.  I misstated the 1).  The term should be 'module,' not 
'program.'  There's only an issue if the module handles exceptions in 
some way, regardless of what other modules in the program are doing.