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 5382

Summary: Issues building static library on Windows with CMake (missing stdlib functions)
Product: SDL Reporter: Philip Bennefall <philip>
Component: buildAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: major    
Priority: P2 CC: sezeroz
Version: 2.0.12   
Hardware: x86   
OS: Windows 10   

Description Philip Bennefall 2020-12-08 09:44:13 UTC 
When trying to build the latest version of SDL (version 2.0.12) with Visual Studio 2017 or 2019 via CMake, I get the following:

SDL_string.c
F:\build\SDL2\src\SDL2_project\src\stdlib\SDL_string.c(442): warning C4013: ‘wcslcpy’ undefined; assuming extern r
eturning int [F:\build\SDL2_build\SDL2-static.vcxproj] [F:\build\SDL2_project.vcxproj]
F:\build\SDL2\src\SDL2_project\src\stdlib\SDL_string.c(458): warning C4013: ‘wcslcat’ undefined; assuming extern r
eturning int [F:\build\SDL2_build\SDL2-static.vcxproj] [F:\build\SDL2_project.vcxproj]

And then I get linker errors. Version 2.0.10 builds just fine. I am building a 32 bit binary.

Digging a little deeper in SDL’s CMake script, I see on line 754:
if(LIBC)
if(WINDOWS AND NOT MINGW)
set(HAVE_LIBC TRUE)

And then a little further down in the same scope, there is a list of functions that are all assumed to be available in the C runtime. If I remove wcslcpy and wcslcat from this list, the build succeeds.

A patch for this as well as a few others for building SDL with CMake, are included in the VCPKG distribution from Microsoft. They are in the ports/SDL2 folder. 

https://github.com/Microsoft/vcpkg
Comment 1 Sam Lantinga 2020-12-08 17:21:28 UTC 
Fixed, thanks!
https://hg.libsdl.org/SDL/rev/0aa5690fb1c8

Also thank you for the heads up on the other patches in that folder. I accepted most of them for the next SDL release.
Comment 2 Ozkan Sezer 2020-12-08 17:39:24 UTC 
This one https://hg.libsdl.org/SDL/rev/be0a46c9b010 is wrong and also
problematic.

The _DLL macro usually is defined by MSVC dll projects, but it is not
defined by our MSVC project files because it has not been needed. The
autotools builds define DLL_EXPORT by way of libtool, but begin_code.h
doesn't check it. The result is: the autotools builds now export all
and every symbol it can find.

Solution would be defining DLL_EXPORT in CMake and MSVC project files
and changing _DLL to DLL_EXPORT in begin_code.h. (It may also be good
to add an extra BUILD_SDL macro to the table like the OS/2 version..)
Also, the satellite projects such as SDL_mixer should be tested with
the changes.
Comment 3 Philip Bennefall 2020-12-08 19:23:43 UTC 
(In reply to Sam Lantinga from comment #1)
> Fixed, thanks!
> https://hg.libsdl.org/SDL/rev/0aa5690fb1c8
> 
> Also thank you for the heads up on the other patches in that folder. I
> accepted most of them for the next SDL release.

Thank you for the quick turnaround! The string function issue was a blocker for me. Much appreciated!
Comment 4 Ozkan Sezer 2020-12-08 20:19:40 UTC 
(In reply to Ozkan Sezer from comment #2)
> This one https://hg.libsdl.org/SDL/rev/be0a46c9b010 is wrong and also
> problematic.
> 
> The _DLL macro usually is defined by MSVC dll projects, but it is not
> defined by our MSVC project files because it has not been needed. The
> autotools builds define DLL_EXPORT by way of libtool, but begin_code.h
> doesn't check it. The result is: the autotools builds now export all
> and every symbol it can find.
> 
> Solution would be defining DLL_EXPORT in CMake and MSVC project files
> and changing _DLL to DLL_EXPORT in begin_code.h. (It may also be good
> to add an extra BUILD_SDL macro to the table like the OS/2 version..)
> Also, the satellite projects such as SDL_mixer should be tested with
> the changes.

Closing again. Opened a new bug #5384 for this dll exports issue.