We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3502 - SDL2 2.0.5 linking dynamically against LIBGCC_S_DW2-1.DLL or MSVCRT.DLL(which might not be part of the OS, thus being a external dependancy)
Summary: SDL2 2.0.5 linking dynamically against LIBGCC_S_DW2-1.DLL or MSVCRT.DLL(which...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: loadso (show other bugs)
Version: 2.0.5
Hardware: x86 Windows 10
: P2 major
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-29 13:45 UTC by superfury
Modified: 2017-08-30 17:57 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description superfury 2016-11-29 13:45:58 UTC 
I notice that, when compiling SDL2 2.0.5 source code(from the libsdl.org 2.0 download page), it links dynamically against LIBGCC_S_DW2-1.DLL. 64-bit builds don't link against it(using MinGW-w64).

Is there any way to fix this? I've been building my application using SDL2 for a while now, but with the latest(and only) MinGW-get installation it either won't compile(2.0.3 gives a lot of errors during the DirectX files, crashing with fatal compiler errors)) or it will link against LIBGCC_S_DW2-1.DLL when SDL 2.0.5 is compiled. I still want to release my software against 32-bit and the now-new 64-bit builds, but I don't want to have to supply the LIBGCC_S_DW2-1.DLL for each release(it shouldn't even be linked against, according to the wiki:

https://wiki.libsdl.org/Installation

"On Windows, SDL does not depend on a C runtime at all, not even for malloc(). This means it's possible to build SDL with almost any Windows compiler and have it work with a program built with any other. Furthermore, it means that SDLmain (the small static .lib file that optionally provides WinMain()) does not force you to deal with Debug vs Release builds in your app, since it doesn't need either a Debug or Release C runtime. One .lib should work everywhere."

But it now requires the LIBGCC_S_DW2-1.DLL in order to even run?
Comment 1 Sam Lantinga 2017-08-19 00:47:09 UTC 
When I build, I use -static-libgcc to avoid this.
Comment 2 superfury 2017-08-28 10:40:48 UTC 
Well, the odd thing is that --static-libgcc --static-libstdc++ doesn't have any effect on that library on mingw 32-bit.
Comment 3 Sam Lantinga 2017-08-28 16:42:57 UTC 
We've seen a bunch of other issues with mingw32. Does it work with mingw-w64 (which also supports 32-bit compiling?)
http://mingw-w64.org/doku.php
Comment 4 superfury 2017-08-30 16:46:46 UTC 
Just tried to compile using MinGW-w64's 32-bit toolchain and manually adding the --static-libgcc --static-libstdc++ to the SDL2.0.5's EXTRA_LDFLAGS line. The LIBGCC_S_DW2-1.DLL isn't there anymore, according to Depends, but it's now still dependant on the Visual C++ runtime(MSVCRT.DLL). One of the reasons I compiled, until this problem occurred, SDL2 was to prevent users using my app to actually need to install the Visual C++ runtime to even use it(64-bit doesn't suffer from that problem).
Comment 5 Sam Lantinga 2017-08-30 17:09:18 UTC 
As far as I know MSVCRT.DLL is installed on every version of Windows. I've never seen a problem with having this as a dependency.

I'm glad those flags removed the dependency on LIBGCC_S_DW2-1.DLL for you!
Comment 6 superfury 2017-08-30 17:13:48 UTC 
MSVCRT.DLL isn't installed in plain Windows 95 afaik? I remember testing my SDL2-based emulator on Windows 95 once, but failed to run within Windows 95(b it as as far as I remember) because the MSVCRT.DLL wasn't found. Needed to scout the internet to get it together with a bunch of other dlls to even get the app running(all because of that MSVCRT.DLL requirement).
Comment 7 superfury 2017-08-30 17:22:29 UTC 
About the library itself:

https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll-with-my-application

Quotes from the page, according to Chris Becke:
msvcrt.dll has become a defacto part of the OS distribution. On windows 98 and 95 and possibly NT4 it was possible to get OS installs without it if one went to care to strip apps like WordPad out of the installation.

Given its ubiquty however, and the fact that since those OSs very few app developers have bothered to ship it, at least since windows 2000 its been an official part of the OS.

Also, from the page(reply to the above quote, by kolen):
First retail version of Windows 95 (4.00.950 without 'a', 'B' or 'C') doesn't have this file
Comment 8 superfury 2017-08-30 17:23:49 UTC 
About the library itself:

https://stackoverflow.com/questions/1073509/should-i-redistribute-msvcrt-dll-with-my-application

Quotes from the page, according to Chris Becke:
msvcrt.dll has become a defacto part of the OS distribution. On windows 98 and 95 and possibly NT4 it was possible to get OS installs without it if one went to care to strip apps like WordPad out of the installation.

Given its ubiquty however, and the fact that since those OSs very few app developers have bothered to ship it, at least since windows 2000 its been an official part of the OS.

Also, from the page(reply to the above quote, by kolen):
First retail version of Windows 95 (4.00.950 without 'a', 'B' or 'C') doesn't have this file
Comment 9 Sam Lantinga 2017-08-30 17:57:59 UTC 
SDL 2.0 doesn't support Windows 95. It supports Windows XP SP3 and newer.