Vcpkg: Issue with SFML

Created on 7 May 2018  Â·  11Comments  Â·  Source: microsoft/vcpkg

Bonjour
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");
    window.setVerticalSyncEnabled(true); 
    window.setFramerateLimit(60); 

    while (window.isOpen()){
        sf::Event event;
        while (window.pollEvent(event))     {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear(sf::Color::Black);
        // draw everything here...
        // window.draw(...);
        window.display();
    }
    return 0;
}

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

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

jpeg62.dll
sfml-graphics-d-2.dll
sfml-system-d-2.dll
sfml-window-d-2.dll
test1_sfml.exe
test1_sfml.ilk
test1_sfml.pdb

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

Most helpful comment

Any chance of a fix ?

All 11 comments

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.

Bonsoir
I confirm it only happen in Debug version not in Release version
I believe this will help the experts to track and fix the issue
Many thanks in advance, Philippe

Le sam. 12 mai 2018 à 23:50, Yehezkel Bernat notifications@github.com a
écrit :

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.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vcpkg/issues/3447#issuecomment-388585579,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABbmjU041QbKcphk8oOWUFCz_B2HhYZ6ks5tx1kMgaJpZM4T013J
.

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

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.

Bonjour
One idea which may help...
When I look in this directory :
..\vcpkginstalled\x64-windows\debug\bin

I can see this list of files :
FLAC++.dll
FLAC++.pdb
FLAC.dll
FLAC.pdb
freetyped.dll
freetyped.pdb
jpeg.pdb
jpeg62.dll
libbz2d.dll
libbz2d.pdb
libpng16d.dll
libpng16d.pdb
ogg.dll
ogg.pdb
OpenAL32.dll
OpenAL32.pdb
sfml-audio-d-2.dll
sfml-audio-d.pdb
sfml-graphics-d-2.dll
sfml-graphics-d.pdb
sfml-network-d-2.dll
sfml-network-d.pdb
sfml-system-d-2.dll
sfml-system-d.pdb
sfml-window-d-2.dll
sfml-window-d.pdb
turbojpeg.dll
turbojpeg.pdb
vorbis.dll
vorbis.pdb
vorbisenc.dll
vorbisenc.pdb
vorbisfile.dll
vorbisfile.pdb
zlibd.pdb
zlibd1.dll

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 ..\vcpkginstalled\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

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.

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.

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.

Any chance of a fix ?

@40tude , I can't reproduce this issue with VS: 15.9.5 and VCPKG: 2018.11.23-nohash.
I can build the project and run it. And I can find the necessary dll files in \x64\debug folder. I think this issue should be fixed.

Thanks for testing it again and noticing the fix.
I see it was fixed with #4957 (the commit description mentions [sfml] Add find_dependency(Freetype)).

Was this page helpful?
0 / 5 - 0 ratings