Messages

1

General / Re: Runtime Mismatch When Attempting to Link SFML Statically

« on: September 29, 2024, 09:36:52 pm »

The pre-built static binaries do not link the runtime libraries statically.

If you want SFML libraries with the runtime linked statically, you'll have to build SFML yourself and pass -DSFML_USE_STATIC_STD_LIBS=ON (or similar) to CMake.

Ah I see, thank you! I suppose I'll have to try that.
Pardon my ignorance, but why not have the static binaries link the runtime libraries statically? Even if there's a good reason for it being the way it is, it would also be convenient to include a version that links the runtime statically in the releases section wouldn't it?

2

General / Runtime Mismatch When Attempting to Link SFML Statically

« on: September 26, 2024, 11:38:33 pm »

Hello, I am encountering many compilation errors when attempting to build my Visual Studio project that has SFML linked statically. I know there are many common pitfalls that trip people up when attempting to link SFML statically, so I've tried to double check the official "SFML and Visual Studio" tutorial for SFML 2.6, I've double checked the "How do I link SFML statically?" portion of the FAQ, and I've visited several forum posts here also related to static linking before posting.

For reference, here is my environment:
- Microsoft Visual Studio Professional 2022 Version 17.9.6
- Specified runtime library for linking is /MTd on the Debug configuration, and /MT on release configuration.
- Building for 64-bit.
- Using the C++17 standard.

With the above information, I have downloaded the appropriate SFML release from the following page:
https://www.sfml-dev.org/download/sfml/2.6.1/

The file I was given from the download is named SFML-2.6.1-windows-vc17-64-bit.zip, which seems appropriate for the above specifications.

In my Visual Studio project, I have set up the include and library directories much like any other library, and ensured they are pointing to the correct place. I then added the desired modules and their dependencies to my debug configuration:

sfml-graphics-s-d.lib
sfml-window-s-d.lib
sfml-system-s-d.lib
opengl32.lib
freetype.lib
winmm.lib
gdi32.lib

Unless I am mistaken, the lib files with a -s suffix are supposed to be the libraries meant for static linkage, and a -d suffix indicates the lib file is for the debug configuration. I also took care when choosing the order these lib files are included, as I was told the order matters. For example, sfml-window-s-d.lib depends on sfml-system-s-d.lib, so sfml-window-s-d.lib was placed earlier in the list. My dependencies for my release configuration look like this:

sfml-graphics-s.lib
sfml-window-s.lib
sfml-system-s.lib
opengl32.lib
freetype.lib
winmm.lib
gdi32.lib

Finally, I have ensured that my project has the SFML_STATIC preprocessor define.

I have done a completely fresh clean and build of my project, but there are still 121 linking errors. Notable among these are many runtime mismatch errors (LNK2038) like the one below:
Error   LNK2038   mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MTd_StaticDebug' in SFML_Learning.obj

SFML_Learning is of course the project name. What is strange here is that I believed this would be a problem with the C-runtime I selected for my project. I expected that I had mistakenly let the option as /MDd rather than /MTd, but my project is in fact set up to link statically. This is reflected in the error message, which seems to be claiming that my project is set to MTd but the library it is attempting to link was built with MDd. This doesn't seem possible/likely considering I'm using the -s lib files provided in the official SFML release, but this is as far as I have been able to go so I am now turning to the forums in hopes there is something obvious I am still missing.