Re: [Mingw-users] Dependency on libgcc_s_dw2-1.dll
- Date: Fri, 18 Sep 2015 15:24:37 +0300
- From: Eli Zaretskii <eliz@xxxxxxx>
- Subject: Re: [Mingw-users] Dependency on libgcc_s_dw2-1.dll
> From: John Brown <johnbrown105@xxxxxxxxxxx>
> Date: Fri, 18 Sep 2015 08:08:46 -0400
> On Fri, 18 Sep 2015 09:53:37 +0300, Eli Zaretskii wrote:
> > [Please don't take this to private mail.]
> Sorry about that. Normally when I reply, Outlook.com sends the response
> to the list, but its behaviour seems to have changed. Now I have to 'Reply
> All' and delete your private address.
You can skip deleting my address, I don't mind receiving an extra
copy. Deleting a duplicate message is easy.
> >> I don't understand. Why does gcc care who calls my C-language DLL?
> > If the DLL you build will throw exceptions, not linking against shared
> > libgcc will prevent those exceptions from being thrown and caught by
> > other DLLs. GCC cannot know whether the applications or DLLs you are
> > building expect that.
> But I am not throwing exceptions, and if this behaviour is to prevent a
> disaster that may or may not happen, why doesn't it do it all the time?
Because it doesn't know whether it will happen. So it tries to err on
the safe side, and provide the feature even if it might not be used.
> >> If my DLL (which neither catches nor throws C++ exceptions)
> > (I don't think only C++ exceptions are affected. Windows supports
> > exceptions in C code as well.)
> It is true that when I build libThis and libThat I don't know whether they
> implement Windows Structured Exception Handling or not unless I inspect
> the source. I consider it unlikely though.
General-purpose tools and libraries cannot avoid doing things which
might be needed, however unlikely that could be, because users have
the right to rely on these features to be there when they need them.
> > In any case, if you don't want the libgcc DLL dependency, and don't
> > want to link against libgcc statically, what other options did you
> > expect to exist?
> I was hoping to avoid linking this (what I consider to be a) C++ DLL to my
> C modules whether statically or dynamically, because I am not (explicitly)
> calling any functions in it.
This is hard to do in a non-trivial program. That library implements
a few opcodes that the processor doesn't have in its firmware;
avoiding that would require intimate knowledge of GCC code
generation. Besides, even if your code doesn't call those functions,
some dependency library might.
> Now that I know, I can follow your suggestion, but does it have any GPL
It does have a GPL implication, but it's for the better: through a
special exception in the GPL, linking against libgcc statically does
NOT require you to provide the sources, while linking against it
dynamically does, because the exception is only valid for static
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: