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 4759

Summary: Unresolved external due to implicit memset
Product: SDL Reporter: Marius Elvert <marius.elvert>
Component: *don't know*Assignee: Ryan C. Gordon <icculus>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: major    
Priority: P2 CC: bodie, hi, sylvain.becker
Version: 2.0.10Keywords: target-2.0.12
Hardware: x86_64   
OS: Windows 10   

Description Marius Elvert 2019-08-11 11:48:06 UTC 
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:\PROGRA~2\Windows Kits\10\bin\10.0.18362.0\x64\rc.exe" --mt="C:\PROGRA~2\Windows Kits\10\bin\10.0.18362.0\x64\mt.exe" --manifests  -- "C:\PROGRA~2\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:\PROGRA~2\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.
Comment 1 Marius Elvert 2019-08-11 13:19:46 UTC 
I've implemented a work-around by adding a memset that calls SDL_memset (See the patch to SDL_string in https://github.com/bincrafters/conan-sdl2/pull/25). No idea what generates the implicit memset here - does not seem to be one of the ordinary array-inits.
Comment 2 Bodie 2019-08-24 12:18:42 UTC 
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.
Comment 3 Bodie 2019-08-24 12:47:11 UTC 
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.
Comment 4 Sylvain 2019-08-24 15:19:00 UTC 
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 ...
Comment 5 Ryan C. Gordon 2019-08-24 20:48:28 UTC 
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.
Comment 6 Ryan C. Gordon 2019-08-24 20:53:18 UTC 
(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.
Comment 7 Sam Lantinga 2019-08-24 23:27:12 UTC 
Actually, why don't we turn that into an SDL_memset()?
Comment 8 Ryan C. Gordon 2019-09-02 04:30:46 UTC 
(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.
Comment 9 Ryan C. Gordon 2019-09-20 20:47:35 UTC 
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.
Comment 10 Ryan C. Gordon 2019-09-20 20:48:42 UTC 
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.
Comment 11 Ryan C. Gordon 2019-09-26 16:58:03 UTC 
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.