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 1820 - building SDL as a static library with static runtime doesn't compile/link with visual studio
Summary: building SDL as a static library with static runtime doesn't compile/link wit...
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: build (show other bugs)
Version: HG 2.0
Hardware: x86 Windows 7
: P2 minor
Assignee: norfanin
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-23 20:41 UTC by Wouter van Oortmerssen
Modified: 2017-07-31 14:30 UTC (History)
5 users (show)

See Also:

Attachments
Adds a condition so only the MSVC 2012 compiler defines the macros for the functions of its version. (1.18 KB, patch)
2013-09-28 13:49 UTC, norfanin 		Details | Diff
Fixes the version check for some functions that are only present with the MSVC 2013 CRT libraries. (401 bytes, patch)
2013-10-12 00:46 UTC, norfanin 		Details | Diff
Show Obsolete (1) View All 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 Wouter van Oortmerssen 2013-04-23 20:41:00 UTC 
I'm building SDL as a static library instead of a DLL, and I am using the static runtimes (/MT /MTd). This appears to conflict with SDL's LIBC replacements and gives a lot of errors when trying to link the resulting .lib against my main application.

I understand that you may prefer DLL builds and DLL runtimes, but to simplify deployment (and avoid WinSxS problems) I build everything statically. I managed to hack around most errors (primarily by commenting out HAVE_LIBC HAVE_ITOA HAVE_STRTOLL HAVE_SSCANF HAVE_M_PI HAVE_COPYSIGN HAVE_SCALBN in the windows config header before building the lib), but having at least a #define or whatever to make SDL compile/link correctly out of the box would be helpful.
Comment 1 Ryan C. Gordon 2013-07-12 22:15:52 UTC 
(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 2.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.
Comment 2 Sam Lantinga 2013-07-27 06:04:35 UTC 
I don't build in this configuration, but if you submit a tested patch to easily switch to static builds I'll be happy to include it.

Thanks!
Comment 3 Wouter van Oortmerssen 2013-07-27 12:17:49 UTC 
I could submit a patch, which would basically consist of an #ifdef around the defines I mention in my original post. But I am afraid that is a hack, since I don't know enough about the SDL internals to know if this change makes sense, or there is something more obvious going wrong elsewhere. If you just try to build in VS statically, you might be able to see why it is not compiling.
Comment 4 Wouter van Oortmerssen 2013-07-27 12:23:25 UTC 
Also, I don't use Mercurial, I may not have time to set this up any time soon.
Comment 5 Sam Lantinga 2013-07-28 14:30:59 UTC 
Okay, I'll take a look at this sometime after the 2.0 release.

Thanks!
Comment 6 Joshua Granick 2013-08-14 16:08:42 UTC 
I very nearly have SDL2 working as a static library. I am currently using CMake with "-DDIRECTX=OFF" set, and there are only a few modifications required.

First, I need "/MT" instead of "/MD" as well, which I had trouble automating through CMake. As a result, I temporarily have modified it myself, changing "MultiThreadedDLL" to "MultiThreaded" and "MultiThreadedDebugDLL" to "MultiThreadedDebug" in the vcxproj file.

Second, there are two symbols defined by /stdlib/SDL_stdlib.c which create a conflict in my project. These are "_fltused" and "_ftol2_sse", which I temporarily commented out. Setting HAVE_LIBC caused a host of errors for me.

Third, I needed additional libs linked in my DLL. These include: "winmm.lib", "imm32.lib", "ole32.lib", "oleaut32.lib", and "version.lib", in addition to "gdi32.lib", "opengl32.lib", "user32.lib", "wldap32.lib" and "shell32.lib" which were already linked. Now one problem remains.

I have one problem when linking:

LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main reference
d in function ___tmainCRTStartup

What would be the fix?
Comment 7 Gabriel Jacobo 2013-08-14 17:03:13 UTC 
Joshua, you need to link in SDL_main probably.

Also, one of our GSOC projects may interest you, and feedback there is always appreciated. https://bitbucket.org/gsocben/sdl-gsoc-2013
Comment 8 Joshua Granick 2013-08-14 17:14:50 UTC 
I am trying to link SDL2 into another static library, I'm sorry that I didn't mention this. As a result, I would expect that there should be no reference to "main" yet, since it isn't an application, but a library?
Comment 9 CD-i Fan 2013-09-23 18:28:05 UTC 
I have SDL 2.0.0 building and as a static library. Everything seems to work so far, but I'm just starting to work with SDL...

I used the following steps:

1) Ensuring that HAVE_LIBC is defined to avoid link conflicts with the standard library. I'm doing that via the project configuration.

2) Uncommenting the following #define's in SDL_config_windows.h:
- HAVE_STRTOLL
- HAVE_SSCANF
- HAVE_M_PI
- HAVE_COPYSIGN
- HAVE_SCALBN

This is with Visual Studio 2010 Professional, in particular step 2 may be different depending on VS version.

I'm using /MT.
Comment 10 norfanin 2013-09-28 13:49:37 UTC 
Created attachment 1341 [details]
Adds a condition so only the MSVC 2012 compiler defines the macros for the functions of its version.

Attaching a patch that adds a condition so that the HAVE_X supported by MSVC 2012 only get defined with that compiler. MSVC 2008 and 2010 will then build without any modification to the SDL source code.

Also moved HAVE_M_PI to a separate check. The Microsoft headers require _USE_MATH_DEFINES to be defined before they define the constants.
Comment 11 Sam Lantinga 2013-09-28 17:31:47 UTC 
Your patch looks good, thanks!
http://hg.libsdl.org/SDL/rev/2f67f0616044
Comment 12 norfanin 2013-10-12 00:46:12 UTC 
Created attachment 1365 [details]
Fixes the version check for some functions that are only present with the MSVC 2013 CRT libraries.

I did my testing wrong and failed to see that 2012 doesn't have these functions. Microsoft implemented them in their upcoming 2013 version, though. The attached patch changes it to the check for the next version.

I also removed the HAVE_ITOA because that would require linking with oldnames.lib and it's easier to just let the SDL implementation take over.
Comment 13 Sam Lantinga 2013-10-14 02:52:28 UTC 
Fixed, thanks!
http://hg.libsdl.org/SDL/rev/c50a384be081