This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.10
Reported for operating system, platform: Windows 10, x86_64

Comments on the original bug report:

On 2019-08-11 11:48:06 +0000, Marius Elvert wrote:

See the linker error on the downstream conan project:

https://ci.appveyor.com/project/bincrafters/conan-sdl2/builds/26613326/job/qwofy2u5y209004x

FAILED: bin/SDL2.dll lib/SDL2.lib
cmd.exe /C "cd . && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E vs_link_dll --intdir=source_subfolder\CMakeFiles\SDL2.dir --rc="C:\PROGRA2\Windows Kits\10\bin\10.0.18362.0\x64\rc.exe" --mt="C:\PROGRA2\Windows Kits\10\bin\10.0.18362.0\x64\mt.exe" --manifests -- "C:\PROGRA2\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\link.exe" /nologo @CMakeFiles\SDL2.rsp /out:bin\SDL2.dll /implib:lib\SDL2.lib /pdb:bin\SDL2.pdb /dll /version:2.0 /machine:x64 /INCREMENTAL:NO /NODEFAULTLIB && cd ."
LINK: command "C:\PROGRA2\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.22.27905\bin\Hostx64\x64\link.exe /nologo @CMakeFiles\SDL2.rsp /out:bin\SDL2.dll /implib:lib\SDL2.lib /pdb:bin\SDL2.pdb /dll /version:2.0 /machine:x64 /INCREMENTAL:NO /NODEFAULTLIB /MANIFEST /MANIFESTFILE:bin\SDL2.dll.manifest" failed (exit code 1120) with the following output:
Creating library lib\SDL2.lib and object lib\SDL2.exp
SDL_string.c.obj : error LNK2019: unresolved external symbol memset referenced in function SDL_vsnprintf_REAL
bin\SDL2.dll : fatal error LNK1120: 1 unresolved externals
ninja: build stopped: subcommand failed.

Looks like this happened because of a VS2019 compiler update from 14.21.27702 to
14.22.27905. Previous builds are fine with the same code.

On 2019-08-11 13:19:46 +0000, Marius Elvert wrote:

I've implemented a work-around by adding a memset that calls SDL_memset (See the patch to SDL_string in bincrafters/conan-sdl2#25). No idea what generates the implicit memset here - does not seem to be one of the ordinary array-inits.

On 2019-08-24 12:18:42 +0000, Bodie wrote:

Hello,

I recently became affected by this bug after updating to the latest Visual Studio 2019 (16.2.3.) I'm building SDL2 as a dependency in a CMake project, and the bug occurs when I build on Windows 10 (10.0.17763 Build 17763) with -DCMAKE_BUILD_TYPE=Release using VS2019 (MSVC 19.22.27905.0).

I was able to build successfully using these parameters in the previous version of VS2019, so my suspicion is that this is a Microsoft implementation issue.

Thanks for filing.

On 2019-08-24 12:47:11 +0000, Bodie wrote:

I've filed a bug report in Visual Studio using the title "Unexpected implicit memset in release-optimized build causes LNK2019 in VS2019 16.2.3" if anyone cares to upvote it.

On 2019-08-24 15:19:00 +0000, Sylvain wrote:

your log says it's in

SDL_string.c.obj : error LNK2019: unresolved external symbol memset referenced in function SDL_vsnprintf_REAL

look at the file:
src/stdlib/SDL_string.c
see which SDL_vsnprintf gets compiled.

find out which line adds an implicit memset ...

On 2019-08-24 20:48:28 +0000, Ryan C. Gordon wrote:

So the usual things that encourage Visual Studio to generate a memset call (a loop that initializes all elements of an array to zero, a local array with an explicit initializer) aren't present in SDL_vsnprintf(). Can you attach SDL_string.c.obj to this report so I can see what the new Visual Studio did?

Thanks,
--ryan.

On 2019-08-24 20:53:18 +0000, Ryan C. Gordon wrote:

(In reply to Ryan C. Gordon from comment # 5)

So the usual things that encourage Visual Studio to generate a memset call
(a loop that initializes all elements of an array to zero, a local array
with an explicit initializer) aren't present in SDL_vsnprintf().

Actually, I was looking at the wrong #ifdef, there are a few possible suspects, like this:

    while (len--) {
        if (textstart+len < end) {
            textstart[len] = fill;
        }
    }

...where the compiler might have gotten smart enough to slot a memset in place of that loop. Send in the .obj and I'll look at it.

--ryan.

On 2019-08-24 23:27:12 +0000, Sam Lantinga wrote:

Actually, why don't we turn that into an SDL_memset()?

On 2019-09-02 04:30:46 +0000, Ryan C. Gordon wrote:

(In reply to Sam Lantinga from comment # 7)

Actually, why don't we turn that into an SDL_memset()?

We can, I just don't want to play whack-a-mole if it turns out there's three other places that need this, which is why I wanted the .obj file. :)

--ryan.

On 2019-09-20 20:47:35 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2019-09-20 20:48:42 +0000, Ryan C. Gordon wrote:

We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.

On 2019-09-26 16:58:03 +0000, Ryan C. Gordon wrote:

Hearing nothing, I replaced some possible culprits in https://hg.libsdl.org/SDL/rev/3def438a1540 but I don't know if I actually got it.

It's worth noting that there are a ton of loops in this file that are just as likely to get replaced with a memset() or memcpy()...they're in SDL_memset and SDL_memcpy, of course.

I'm wondering if we should just implement a few of these standard functions when #ifdef _MSC_VER and not export them outside the DLL, so the next time Visual Studio inserts a memset() call, it resolves to inside SDL, and nothing external see is. There are probably a million ways this can go wrong, though.

For now, I'm closing this bug. If the problem still persists, please reopen.

--ryan.