CMake cannot find SFML

[texus]

Somewhere inside your "c:/Users/luka-/OneDrive/Desktop/AutoBackupScript2/build" folder. Probably inside the "TGUI/lib/Debug" subdirectory.

There is a way to let CMake automatically copy the dll when building. Try adding the following to your cmake script: (I didn't test this so it might not work as-is)

Code (cmake) Select Expand

add_custom_command(
    TARGET AutoBackupScript POST_BUILD
    COMMAND ${CMAKE_COMMAND} -E copy "$<TARGET_FILE:tgui>" "."
    VERBATIM)

[luka]

The command copied or created the .dll, but the application still crashes. When attempting to start the .exe in the build directory, I now receive an error stating that the file doesn't exist or is not suitable for Windows. Error code: 0xc000012f

In VS Code, the application crashes with the error "Command executed, took 85ms and failed (Exit code 1).

[texus]

0xc000012f seems to mean that the "Microsoft Visual C++ Redistributable" isn't installed, which is a bit weird in this case. To run any software that was build with Visual Studio, you need to have the redistributable installed for that Visual Studio version. It raises a question though: what code is built with Visual C++? You are building with MinGW, the precompiled SFML libraries were build with MinGW, and TGUI is being build together with your project and also with the MinGW compiler.

Is the bin directory of your MinGW compiler in your PATH environment variable?
Just to be safe, can you copy libgcc_s_seh-1.dll, libstdc++-6.dll and libwinpthread-1.dll from "C:\mingw64\bin\" and place them next to your exe?

[luka]

0xc000012f seems to mean that the "Microsoft Visual C++ Redistributable" isn't installed, which is a bit weird in this case. To run any software that was build with Visual Studio, you need to have the redistributable installed for that Visual Studio version. It raises a question though: what code is built with Visual C++? You are building with MinGW, the precompiled SFML libraries were build with MinGW, and TGUI is being build together with your project and also with the MinGW compiler.

It seems like it, but that is super confusing.

They are already in there. My CMake script copies all SFML and MinGW .dll files into the build directory while configuring the project.

[texus]

I'm not sure how much I can help with this issue.

One thing you could still try is to use the precompiled TGUI libraries for MinGW 64bit instead of building them yourself, although I doubt that it will solve anything.

Have you tried reinstalling the latest Microsoft Visual C++ Redistributable version just to be sure?

Could you create a zip file with the exe, SFML dlls, TGUI dll and the 3 gcc dlls that I mentioned in my previous post and send those to me? Then I can try testing if I find anything weird with it.
Could you also post the current CMake script that you are using? Maybe I can try building the same way here and see if I can reproduce it or not.

[luka]

Thank you. I tried reinstalling it, and here's the zip archive. I included the entire build directory to ensure you have everything. The 'CMakeLists.txt' is provided below.


https://www.file2send.eu/de/download/GEhzYpN1BJhd2Y1m0MgbUMYLQyCJkkVeKlb6AedpqskgnzPtTUlKRuBdINyfGF1J

Code Select Expand

cmake_minimum_required(VERSION 3.17)
project(AutoBackupScript VERSION 0.1.0 LANGUAGES C CXX)

set(CMAKE_CXX_STANDARD 20)

include_directories(headers)
set(SFML_DIR "c:/SFML/lib/cmake/SFML")  # Pfad zum SFML CMake-Modul
add_subdirectory(TGUI)

# list of source files
set(SOURCES
    #src/main.cpp
    src/ScalableLoginScreen.cpp
)


# add executable
add_executable(AutoBackupScript ${SOURCES})


target_link_libraries(AutoBackupScript PRIVATE TGUI::TGUI)

# searching and linking sfml
find_package(SFML COMPONENTS system window graphics network audio REQUIRED)
if (SFML_FOUND)
    target_link_libraries(AutoBackupScript PRIVATE sfml-system sfml-window sfml-graphics sfml-network sfml-audio)
endif()

add_custom_command(
    TARGET AutoBackupScript POST_BUILD
    COMMAND ${CMAKE_COMMAND} -E copy "$<TARGET_FILE:tgui>" "."
    VERBATIM)

# copying the Dll files in the build directory
if(WIN32)
    file(GLOB BINARY_DEP_DLLS "c:/SFML/bin/*.dll")
    file(COPY ${BINARY_DEP_DLLS} DESTINATION ${CMAKE_BINARY_DIR})
    file(GLOB MINGW_DEP_DLLS "C:/mingw64/bin/*.dll")
    file(COPY ${MINGW_DEP_DLLS} DESTINATION ${CMAKE_BINARY_DIR})
endif()



[texus]

I have no idea how it's even possible, but something looks wrong with that TGUI dll. The size of your dll is smaller than the ones I have. Even the 32bit dlls that I have are still larger than the tgui-d.dll that was generated on your pc.

I've downloaded the "MinGW-w64 13.1.0 - x86_64‑posix‑seh (64bit)" version of TGUI 1.2.0 from https://tgui.eu/download/ and copied the tgui-d.dll from the bin folder of the zip file into your build_directory and afterwards I could run your exe just fine (after also copying xubuntu_bg_aluminium.jpg into the build_directory).

EDIT: Your dll file isn't even recognized as a valid DLL by the tools that I have to dump dll information.
EDIT 2: The first 1536 bytes (= exactly 3 * 512 bytes) in your DLL are all 0-bytes, so the file looks corrupted. Have you tried deleting the file and letting your cmake project generate it again?

[luka]

EDIT: Your dll file isn't even recognized as a valid DLL by the tools that I have to dump dll information.
EDIT 2: The first 1536 bytes (= exactly 3 * 512 bytes) in your DLL are all 0-bytes, so the file looks corrupted. Have you tried deleting the file and letting your cmake project generate it again?

I tried deleting it and copying it with the CMake script, but I still encountered the same error. So, I attempted to locate the file where it's being copied from, but I couldn't find anything. Is it possible that the file is not in the folder and CMake creates it?

Copying the tgui-d.dll from TGUI 1.2.0 works in VS Code and directly from the directory. Thank you very much.

[texus]

but I couldn't find anything. Is it possible that the file is not in the folder and CMake creates it?

The file has to be created by CMake somewhere in your build directory. Deleting the entire build directory should cause it to be recreated from scratch instead of from cached files.

The most important thing is that you got it working now though.