New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with SFML #3447

40tude opened this Issue May 7, 2018 · 9 comments


None yet
6 participants

40tude commented May 7, 2018

I use

  • Windows 10 fresh install in a VM (1709 - 16299.371 - fr-fr locale)
  • Visual Studio Community 15.6.7
  • vcpkg 0.0.110-2018-05-05-1c49195f789b7b8d7eaeb2542730a1f72cfbefcf

I successfully install the sfml package
.\vcpkg install sfml:x64-windows

I successfully integrate vcpkg with Visual Studio
vcpkg integrate install
Note : I had to install the english package for Visual Studio

I successfully build a 64 bit sample project (debug version).Here is the complete source code :

#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>

int main(){

	sf::RenderWindow window(sf::VideoMode(800, 600), "My window");
	while (window.isOpen()){
		sf::Event event;
		while (window.pollEvent(event))		{
			if (event.type == sf::Event::Closed)

		// draw everything here...
		// window.draw(...);
	return 0;

However when I run it with F5 the application complains because the hereafter DLL is missing

When I look in the x64/Debug directory, close to my code, I can see the following dlls :


If I look for freetype.dll I can find one instance in C:\Users\Philippe\Documents\temp\vcpkg\packages\freetype_x64-windows\bin

My understanding is that in order to build SFML, vcpkg downloaded and compiled successfuly freetype package.

If I copy freetype.dll close to my executable (in the x64/Debug directory) and run the code again I have similar messages for the following DLLs

  • zlib1.dll
  • libpng16.dll
  • libbz2.dll

For each of them I can find the correct DLL in the ../vcpkg/XYZ directory
Again my understanding is that vcpkg downoladed and compiled correctly the last three projects.

At the end when all the DLLs were pasted close to the executable I was able to run and debug my code.

However, I don't know how vcpkg miss the dependencies that exist between the SFML DLLs and the 4 DLLs (freetype, zlib1...)
What is really weird for me is that vcpk did an excellent job tracking the dependency between jpeg62.dll and some of the SFML DLLs
Again look at the initial content of the directory after the first build. jpgeg62.dll has been copied correctly.

From the user point of view vcpkg should track the dependencies and copy the 4 missing DLLs

I hope this report will help you to improve vcpgk
Many thanks in advance and, please, keep doing the excellent job (a package manager is key for the C++ community)
Regards, Philippe


This comment has been minimized.


YehezkelShB commented May 12, 2018

I encountered this issue too (and so are many of my students...).
One interesting point I have noticed is that this happens only on Debug builds and not on Release builds. x86/x64 selection doesn't affect it, with either of the options it happens for Debug build but copies all the needed DLLs for Release build.

I understand that vcpkg uses dumpbin for inspecting dependencies. Both sfml-graphics-2.dll and sfml-graphics-d-2.dll mention freetype.dll when using dumpbin /dependents on them.


This comment has been minimized.

40tude commented May 13, 2018


This comment has been minimized.

40tude commented May 14, 2018

1 - Is there any further we could/should/can do to help and make progress on this issue?
2 - Any suggestion?
Regards, Philippe


This comment has been minimized.

headkase commented May 16, 2018

I am also affected by this issue. SFML x64-windows triplet. Tried the x86 triplet as well with the same result as already stated in this thread.


This comment has been minimized.

40tude commented May 22, 2018

One idea which may help...
When I look in this directory :

I can see this list of files :

Note that the freetype DLL is in fact named freetyped.dll
It seems there is 2 things happening :
1 - In debug mode, not all the debug version of the DLLs are copied in the directory of the solution
2- I'm wondering if it has anything to do with the fact that in debug mode freetype.dll is named freetyped.dll

Please not that it seems this is the same thing for the 3 others DLLs :
Expected In ..\vcpkg\installed\x64-windows\debug\bin
zlib1.dll -------------------> zlibd1.dll
libpng16.dll---------------> libpng16d.dll
libbz2.dll -----------------> libbz2d.dll

My belief is :
In release mode the generated DLL have the correct names so everything works fine (all the DLLs are copied in the Solution directory).
However, in Debug mode the DLLs names are decorated with "d" and so when one (who, I don't know who yet :-) ) try to copy zlib1.dll from the Debug repos to the solution directory then it can't find it and nothing is copied.

Proposed solutions :
1 - No matter the version (Debug or Release) the DLLs names should not be decorated with ending "d"
2 - If the Debug version of the DLL are decorated with ending "d" then make sure the script/build system use the correct names when it try to copy the DLL files from the repos to the project directory.

I would vote for Option 1

One final note : To tell the truth I'm quite surprised no one take the time to confirm what is said here by different sources. We (the reporters) don't even know if someone in charge is reading our feedback.

Again, I would more than happy to help but I don't know where to start and I don't know how to contact the maintainer of the SFML vcpk package directly.

Coud someone take the time to confirm he red this thread of mail?
Best regards, Philippe


This comment has been minimized.

CharlesUnruh commented May 23, 2018

Writing to back the validity of this issue. I'm seeing the exact same symptoms on a fresh install of VS 2017, with a fresh version of vcpkg, with US English locales (VS Installed yesterday, vcpkg installed today). I'm trying to build using SFML and debug builds are not properly copying the debug versions of their requisite DLLs, while release builds are successful.


This comment has been minimized.

CharlesUnruh commented May 24, 2018

I've left this in the LCMS thread, but I wanted to touch back here because of its relevance.

I tested by placing freetyped.dll next to the executable and running it. It crashed with the error above. I then renamed freetyped.dll to freetype.dll and it now errors out on the missing DLL dependencies of Freetype, but it mentions these explicitly as the debug versions. E.G. "libpng16d.dll", "zlibd1.dll", and "libbz2d.dll".

It's interesting to note that the executable is expecting the non-debug freetype.dll, while the executable is expecting the debug versions of freetype's dependencies.


This comment has been minimized.

kleszcz commented Jun 27, 2018

I've tried adding freetype and zlib explicitly to my CMakeLists and target_link_libraries so they'll be copied but it hasn't helped. Only when I've directly included freetype.h and zlib.h in my code the dll's have been copied into Debug folder along the exec. Although freetyped.dll has been copied (which is correct) and I've to duplicate the file and rename it to freetype.dll.


This comment has been minimized.

aleksandras-fatmap commented Jul 9, 2018

Any chance of a fix ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment