Dependency on libgcc_s_dw2-1.dll

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Dependency on libgcc_s_dw2-1.dll

John Brown
Hello All,

What is the purpose of libgcc_s_dw2-1.dll? I always thought that it had
something to do with C++ exceptions, but many of the DLLs that I have
built recently depend on it, even though the source is not C++ as far
as I can see.

Regards,
John Brown.
     
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Dependency on libgcc_s_dw2-1.dll

Eli Zaretskii
> From: John Brown <[hidden email]>
> Date: Thu, 17 Sep 2015 13:15:01 -0400
>
> What is the purpose of libgcc_s_dw2-1.dll? I always thought that it had
> something to do with C++ exceptions

Yes, that's its purpose.

> but many of the DLLs that I have built recently depend on it, even
> though the source is not C++ as far as I can see.

GCC cannot possibly know if the libraries you build will be loaded by
C++ programs.

You need to work harder to avoid the dependency, see

  http://www.mingw.org/wiki/HOWTO_Sneak_GCC_Switches_Past_Libtool


------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Dependency on libgcc_s_dw2-1.dll

Eli Zaretskii
[Please don't take this to private mail.]

> From: John Brown <[hidden email]>
> Date: Thu, 17 Sep 2015 17:29:10 -0400
>
> 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.

> 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.)

> is called by a C++ module, then let *that* module link to
> libgcc_s_dw2.dll if it catches or throws exceptions.

You need both the throwing and the catching code to link against the
shared libgcc.

> What specifically causes libgcc_s_dw2-11.dll to be linked?

Some code generated by GCC calls functions in libgcc.  By default, the
MinGW GCC is configured to link in the shared version of libgcc.  You
can see that in the output of "gcc -dumpspecs".

> Merely calling  C functions doesn't cause it.

You need to call a function that requires routines in libgcc.

> > You need to work harder to avoid the dependency, see
> >
> > http://www.mingw.org/wiki/HOWTO_Sneak_GCC_Switches_Past_Libtool
>
> I don't particularly want to link libgcc statically. My understanding was that it was
> bad for a DLL to link statically to the C runtime because if it is called by a program
> that was built against another C runtime then you could get hard-to-find bugs.

libgcc is NOT the C runtime.  It includes a small number of support
routines that have nothing to do with C runtime.

Moreover, the problems with static linking that you describe can only
happen if you pass objects (like 'FILE *') created by one version of
runtime to a function (like 'fprintf') from another.  This cannot
possibly happen with libgcc, since C programs never actually call
functions from libgcc in their source code, and thus don't access any
values those functions return.

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?


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Dependency on libgcc_s_dw2-1.dll

John Brown


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.

>>
>> 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?

>> 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.

>> is called by a C++ module, then let *that* module link to
>> libgcc_s_dw2.dll if it catches or throws exceptions.
>
> You need both the throwing and the catching code to link against the
> shared libgcc.
>

[snip]

> 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. Of course, if the default action were to link statically,
I wouldn't have known that it was happening and I would have continued in
blissful ignorance.

Now that I know, I can follow your suggestion, but does it have any GPL
implications?

Regards,
John Brown.

     
------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Dependency on libgcc_s_dw2-1.dll

Eli Zaretskii
> From: John Brown <[hidden email]>
> 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
> implications?

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
linking.


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe