Messages

1

General / Vanilla SFML 3 Compilation: No BUILD_SHARED_LIBS Option in CMake

« on: February 15, 2025, 09:27:49 am »

I just tried compiling SFML 3 on windows 11 using
- MinGW-W64 x86_64-ucrt-posix-seh 14.2.0
- cmake version 3.31.5

I ended up creating files such as
libsfml-audio-s-d.a
libsfml-audio-s.a
etc.
I guess these are static libraries? Usually shared libs have been build in the "default setting" when you don't touch anything in CMake.

The tutorial here
https://www.sfml-dev.org/tutorials/3.0/getting-started/build-from-source/#configuring-your-sfml-build
states, that CMake provides a boolean Option BUILD_SHARED_LIBS. But its nowhere displayed in cmake-gui:
How can i build the shared libs using cmake-gui? Am i out of luck?



EDIT: There is a small Button "Add Entry" in Cmake-GUI, which let me add BUILD_SHARED_LIBS to the configuration. But i think it still should be there by default? Compiling SFML with that Option enabled created the right files (sfml-graphics-d-3.dll etc.)

2

General / SFML with GCC on MacOS

« on: October 06, 2024, 11:57:18 am »

I installed SFML on MacOS with

brew install sfml

a sample project compiles just fine with the default c++ compiler on MacOS which is Clang16 on my machine.
CMake's "find_package" works flawlessly and finds SFML. Great!
However, Clang 16 seems to not support C++20-Modules, so I installed Clang19 and GCC-14.2 via homebrew, which both do support Modules:

brew install llvm

brew install gcc

When i setup the Toolchain in Clion with these compilers i can run a hello-world example printing to std::cout without problems. However, the moment i include the SFML Libraries both Compilers give me a plethora of weird error messages.

I did the same thing with GCC-14.2 on Windows with the difference, that here i compiled SFML with that same GCC-14.2 Compiler and i can run the project using SFML and Modules on Windows.

So i assume that the installed version of SFML, that i got with brew, is not compatible with GCC-14.2  or Clang 19.
How would i proceed from here?
Is there a way to reinstall SFML with brew in a "GCC-14.2" or "Clang19" version? Or do i need to compile the SFML Source Code with one of these compilers and replace the files brew installed with the new files?
I cannot find anywhere information how to make brew installed libraries to work with other compilers. Maybe someone can give me a push in the right direction, thanks!

EDIT: I got it to compile after some detours.
1. I uninstalled the SFML version i got via brew with

brew uninstall sfml

2. I installed the newest llvm version (llvm 19) with brew:

brew install llvm

3. I added it to the path, so i could use the new compiler via the terminal

echo 'export PATH="/opt/homebrew/opt/llvm/bin:$PATH"' >> ~/.zshrc

4. next i got the newest SFML version, compiling it with the new clang19 compiler and enabling shared libs and finally installed it:

git clone https://github.com/SFML/SFML.git
cd SFML
mkdir build && cd build
cmake .. -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DBUILD_SHARED_LIBS=ON
make
sudo make install

An interesting note: I was not allowed to compile it with GCC. CMake outright refused it with a message stating that SFML is only allowed to be compiled with clang on MacOS" or someting like that. Thats why i used Clang and not GCC for compiling SFML on MacOS.
All relevant SFML libraries were now being saved to /usr/local/lib
5. The CMakeLists.txt File looks like this:

cmake_minimum_required(VERSION 3.28)
project(myProject LANGUAGES CXX)

find_package(SFML COMPONENTS System Graphics)

set(SOURCES main.cpp)
include_directories(/Users/UserName/Documents/Programming/SFML/include)
add_executable(myProject ${SOURCES})
target_sources(myProject
        PUBLIC
        FILE_SET CXX_MODULES FILES
        Window.cppm
        Game.cppm
)
target_compile_features(myProject PRIVATE cxx_std_23)
target_link_libraries(myProject /Users/UserName/Documents/Programming/SFML/extlibs/libs-macos/Frameworks/freetype.framework/Versions/A/freetype SFML::System SFML::Graphics)

I had problems with FreeType which would not be recognized, even when installed via "brew install freetype". I had to link against the provided freetype file that comes with the SFML Source Code in the folder "extlibs". Also, despite find_package(...) being able to find SFML, the SFML Include Files were not available, thus i had to include them manually via "include_directories(...) in CMakeLists.txt. After that, the program finally compiled. I can now use C++ Modules with SFML 3 RC on my MacOS System.

3

General / Re: console disable c++

« on: April 30, 2023, 08:00:31 pm »

this blogpost might help you, which covers the topic:
"Getting rid of the console window using SFML and CMake on Windows-OS"

http://zaunfish.blogspot.com/2017/

4

General / Re: Unable to use RSFML

« on: July 31, 2022, 12:34:48 pm »

This blog article might be helpful
https://zaunfish.blogspot.com/2022/07/setting-up-rust-sfml-with-mingw-w64-on.html

5

General / CMake: Could not find a configuration file for package "SFML" that is compatible

« on: January 23, 2022, 08:49:23 am »

I have a hard time compiling SFML on my machine.
In the past i have done the following procedure like a 1000 times without having any issues, but now i receive the following error:

CMake Error at CMakeLists.txt:5 (find_package):
  Could not find a configuration file for package "SFML" that is compatible
  with requested version "2.5".

  The following configuration files were considered but not accepted:

    C:/Program Files (x86)/SFML/lib/cmake/SFML/SFMLConfig.cmake, version: 3.0.0



-- Configuring incomplete, errors occurred!
See also "C:/src/test/build/CMakeFiles/CMakeOutput.log".

I compiled SFML on different Windows Versions (10 and 11) and used different versions of mingw-w64 (from https://winlibs.com/), but i always get this error. I never had this issue before. The steps i did:

• Get SFML from Github
• Create Makefiles with CMake, using MinGW Makefiles as generator
• run "mingw32-make install" in the CMake-Build-Folder that i need to select in CMake-GUI

I use this basic CMakeLists.txt-file to build the project:

cmake_minimum_required(VERSION 3.1)

project(SFMLTest)

## If you want to link SFML statically
# set(SFML_STATIC_LIBRARIES TRUE)

## In most cases better set in the CMake cache
# set(SFML_DIR "<sfml root prefix>/lib/cmake/SFML")

find_package(SFML 2.5 COMPONENTS graphics audio REQUIRED)
add_executable(SFMLTest main.cpp)
target_link_libraries(SFMLTest sfml-graphics sfml-audio)

Here a similar error-message has been discussed: https://github.com/SFML/SFML/issues/1593
OP stated at one point "You were right. I used the wrong compiler in this project. Thank you!", however i don't think this is the reason in my case why find_package() does not work anymore.

EDIT: When i did the exact same steps described above with the SFML-Source from here:
https://www.sfml-dev.org/files/SFML-2.5.1-sources.zip
the described error does not occure.

I also double-checked this. The error can be reproduced if i use the Github Source-Code. When i use the source from https://www.sfml-dev.org/files/SFML-2.5.1-sources.zip everything is ok. 

6

General / Can't compile SFML on Windows 11

« on: October 17, 2021, 07:38:24 pm »

[EDIT]
I could pinpoint the issue: https://winlibs.com/ offers two versions of the mingw-w64 compiler: One ships with UCRT runtime, the other with MSVCRT runtime. With MSVCRT runtime i had no compilation issues. Visual Studio Compiler also had no issues compiling SFML on Windows 11. So i guess its something with the UCRT runtime.
[/EDIT]


I tried to compile SFML on Windows 11 and it fails with the following error-message:

[ 79%] Building CXX object src/SFML/Graphics/CMakeFiles/sfml-graphics.dir/RenderTextureImpl.cpp.obj
[ 79%] Building CXX object src/SFML/Graphics/CMakeFiles/sfml-graphics.dir/RenderTextureImplFBO.cpp.obj
[ 80%] Building CXX object src/SFML/Graphics/CMakeFiles/sfml-graphics.dir/RenderTextureImplDefault.cpp.obj
[ 81%] Building RC object src/SFML/Graphics/CMakeFiles/sfml-graphics.dir/sfml-graphics.rc.obj
[ 82%] Linking CXX shared library ..\..\..\lib\sfml-graphics-2.dll
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/Keen/Downloads/SFML-master/extlibs/libs-mingw/x64/libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x5614): undefined reference to `_setjmp'
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/Keen/Downloads/SFML-master/extlibs/libs-mingw/x64/libfreetype.a(smooth.c.obj):smooth.c:(.text+0x77a): undefined reference to `_setjmp'
collect2.exe: error: ld returned 1 exit status
mingw32-make[2]: *** [src\SFML\Graphics\CMakeFiles\sfml-graphics.dir\build.make:602: lib/sfml-graphics-2.dll] Error 1
mingw32-make[1]: *** [CMakeFiles\Makefile2:307: src/SFML/Graphics/CMakeFiles/sfml-graphics.dir/all] Error 2
mingw32-make: *** [makefile:155: all] Error 2

I did not have this issue on Windows 10 using the same procedure described below:

• 1. I use mingw-w64 compiler from https://winlibs.com/ (GCC 11.2.0 + LLVM/Clang/LLD/LLDB 13.0.0 + MinGW-w64 9.0.0 - UCRT-Runtime)
  
• 2. Download SFML from https://github.com/SFML/SFML
  
• 3. generate CMake-Files for MinGW.
  
• 4. in Build-Folder: "mingw32-make install"
  

It compiles until 82 % and than cannot find '_setjmp'.
Compilation of SFML always worked for me in the past, this is the first time that it cannot get through to 100 %. Maybe it has something to do with Win 11?

7

Network / Re: Sending sf::Packet via asio fails partly

« on: September 10, 2021, 11:37:43 pm »

Thank you for the replies! Laurents answer got me on the right track.
I changed the function to

void Server::handle_receive(const asio::error_code &error, std::size_t l_receivedBytes) {
    sf::Packet packet;
    std::cout << "received bytes: " << int(l_receivedBytes) << "\n";
    packet.append(m_receiveBuffer.data(), l_receivedBytes);
    uint8_t num1; uint8_t num2;
    packet >> num1 >> num2;
    std::cout << int(num1) << ", " << int(num2) << ".\n"; // Output: 5, 6
    receiveData();
}

and now the console prints the right values. One of the reasons i got it wrong at first was that i initially even tried using

uint8_t num1

instead of

int num1

but printing uint_t to the console resulted  in strange symbols displayed in the console instead of the numerical values, therefore i wrongly assumed that i produced an error using uint8_t and switched to int, which at least printed some numerical values to the console. My bad. 

However, every time i use some other library (like asio) it reminds me about how well designed SFML is and how effectively it is in hiding the confusing low-level stuff, while still allowing to mix it with low-level libs, if needed.

8

Network / Re: Sending sf::Packet via asio fails partly

« on: September 10, 2021, 10:43:41 am »

i found out that the checkSize() method from

// SFML Packet.cpp
Packet& Packet::operator >>(Int32& data)
{
    if (checkSize(sizeof(data)))
    {
        std::memcpy(&data, &m_data[m_readPos], sizeof(data));
        data = ntohl(data);
        m_readPos += sizeof(data);
    }

    return *this;
}

returns false, thus the data does not get copied into the Int32& data parameter. But i don't know why the check fails.

9

Network / Sending sf::Packet via asio fails partly

« on: September 09, 2021, 09:16:27 pm »

I programmed a pong multiplayer game using SFML, where i used sf::UdpSockets for transferring data between two PCs. It worked great. Next i wanted to check out how the result would look like if i used the asio network library for networking instead of the SFML Network-classes.

Here my first big issue was, that asio does not provide a class similar to sf::Packet that helps with serializing the data.
With SFML its so beautifully simple, for example if you want to store an enum and some data that belongs to the enum, you could just do:

enum class CommandsToServer{
        Connect, // empty
        Disconnect, // empty
        Data // Vector2f
};
...

sf::Packet packet;
packet << static_cast<uint8_t>(CommandsToServer::Data);
packet << x << y;

and send the packet to the server, where you unpack the content the same way you put it in.

uint8_t command;
uint8_t x, y;
// ... receive packet from socket ...
receivedPacket >> command >> x >> y;
CommandToServer commandToServer = static_cast<CommandToServer>(command);
 

Since i did not find a straightforward way to pack different types into an array, i just used sf::Packet again with the asio::ip::udp::socket.

This approach looks like this:

    m_packet << static_cast<uint8_t>(5);
    m_packet << static_cast<uint8_t>(6);
    m_socket.send_to(asio::buffer(m_packet.getData(), m_packet.getDataSize()), m_serverEndpoint);

So i just try to transfer two values over the network: 5 and 6.

On the server-side i use

std::array<char, 256> m_receiveBuffer;
...
// in some function
    m_socket.async_receive_from(
            asio::buffer(m_receiveBuffer), m_remoteEndpoint,
            std::bind(&Server::handle_receive, this,
                      std::placeholders::_1,
                      std::placeholders::_2));
 ...

void Server::handle_receive(const asio::error_code &error, std::size_t l_receivedBytes) {
    sf::Packet packet;
    std::cout << "received bytes: " << int(l_receivedBytes) << "\n"; // Output: received bytes 2
    packet.append(m_receiveBuffer.data(), l_receivedBytes);
    int num1; int num2;
    packet >> num1 >> num2;
    std::cout << num1 << ", " << num2 << ".\n"; // Output: 0, 0
    receiveData();
 

Console prints 0, 0. But if i start the debugger and set a breakpoint at the last std::cout-statement, i can see that
packet has the following members:
m_data
[ 0 ] = {char}5 '\005'
[ 1 ] = {char}6 '\006’
m_readPos = 0
m_sendPos = 0
m_isValid = false

Its strange because the values 5 and 6 have apparently been transferred successfully, since they are stored in the std::vector<char> container of sf::Packet. However, they don't get transferred via the >> operator into the variables num1 and num2. I don't know the reason why i cannot transfer the data out of the sf::Packet into the variables on the server-side.

10

General discussions / Re: SFML Game Development by Example - 4th SFML book

« on: October 27, 2020, 11:47:21 pm »

Hi OrderNexus,
i may have discovered a subtle bug in the EventManager-Class.

EventManager.h

struct EventInfo{
        EventInfo(){ m_code = 0; }
        EventInfo(int l_event){ m_code = l_event; }
        EventInfo(const GUI_Event& l_guiEvent){ m_gui = l_guiEvent; }
        union {
                int m_code;
                GUI_Event m_gui;
        };
};

If no argument is passed to an EventInfo Constructor during Object-Creation, the EventInfo's default constructor is invoked which initializes the union member int m_code to 0. So when creating an EventInfo object with a default constructor you are not allowed to use the other union member (here m_gui), this would lead to undefined behaviour.

EventManager.cpp

void EventManager::LoadBindings(){
    ...
        EventInfo eventInfo;
        if (type == EventType::GUI_Click || type == EventType::GUI_Release ||
            type == EventType::GUI_Hover || type == EventType::GUI_Leave)
        {
               ...
        eventInfo.m_gui.m_interface = w;
        eventInfo.m_gui.m_element = e;
        }
 ....

in EventManager::LoadBindings() an EventInfo-object is created with a default constructor (EventInfo eventInfo). However further down below, if the EventType is some GUI-Type, the eventInfo.m_gui-variable is getting assigned to the data that is read from the config-file (here w & e). I consider this assignmeht as undefined since the created EventInfo-Object can only use the "int"-variable from its union-members. Or am i missing here something?

11

General / Re: MinGW + SFML + CLion (Windows 10)

« on: April 09, 2020, 11:38:40 am »

Hey there,
i use a similar setup as you (but mingw-w64 instead of mingw). I had also some trouble getting newest SFML version to run with CMAKE and CLION. However with Laurents help i was able to get it to run. Here the whole process is described in detail, it may be helpful for you.

https://en.sfml-dev.org/forums/index.php?topic=26960.0

12

General / Re: SFML 2.5 CMake configuration

« on: February 22, 2020, 08:32:13 pm »

i altered step Nr.6 (and Nr.12) with the command „mingw32-make install". It builds the libs in "C:\Program Files (x86)\SFML". However the strange behaviour remains the same :-(

Then you must set SFML_DIR to C:\Program Files (x86)\SFML, not C:\SFML.

This finally did the trick, everything works now as expected in Clion. Thanks a lot!

13

General / Re: SFML 2.5 CMake configuration

« on: February 22, 2020, 01:44:08 pm »

i altered step Nr.6 (and Nr.12) with the command „mingw32-make install". It builds the libs in "C:\Program Files (x86)\SFML". However the strange behaviour remains the same :-(

When i don't touch Clion everything works as expected. The Release-Build and Debug-Build of my SFML-Application both gets compiled and run fine.
However when the last Build of SFML with "mingw32-make install" is done with CMAKE_BUILD_TYPE=Debug and i additionally open up Clion and run my SFML-Application in "Release-Mode" the Release-Build of my Program breaks because he searches for *-d-2.dll files (as shown in Nr.15 above).

When i erase all files in the cmake-release-build-Folder and compile everything from scratch via CMD exactly how i done it before i opened and compiled it with Clion, it compiles fine, but the application still won't start because a "*-d-2.dll" is missing which makes no sense since i did run cmake with -DCMAKE_BUILD_TYPE=Release when invoking it from the cmake-release-build-Folder.

Clion seems to scramble something because when i don't touch the SFML-Application with Clion, everything works flawlessly and as expected.

What irritates me the most is that i can't get it to run properly after i compiled my SFML-Program with Clion, except i delete C:/SFML and build it again from scratch.

14

General / Re: SFML 2.5 CMake configuration

« on: February 21, 2020, 09:42:42 pm »

Hi Laurent,
i was able to tackle the issue further down. It seems to be not related to the new SFML CMake System but to my IDE (Clion). Here are the exact steps that lead to the error i encountered. I noticed that when i compile everything "by hand" via CMD the error does not occure. However compiling with CLion provokes the error.
In Detail:

Steps:
1.   Download SFML from Github


2.   Extract ZIP-Contents to Download-Folder

3.   Open Up CMake
-   Set „Where is the source code“ to SFML-Directory in Download-Folder
-   Set „Where to build the binaries“ to C:/SFML which will be the place to store all SFML libraries


4.   Click on „Configure“, specify the Generator to „MinGW Makefiles“ since i use mingw-w64-compiler, use checkbox „Use default native compilers“, click „Ok“


5.   Set „CMAKE_BUILD_TYPE“ to „Release“
and click on „Generate“


6.   Open CMD in administrator-mode, go to C:/SFML, compile the generated CMake-Makefile with command „mingw32-make“


7.   I receive this compiled Libraries in C:/SFML/libs


8.   I copy the received dll-files (for example „sfml-graphics-2.dll“) from C:/SFML/libs to the Destination-Folder where the release-version of my SFML-Application is going to be compiled. Here it is „D:\Nextcloud\C++\observer4\cmake-build-release“


9.   I open up CMD, go to that folder where the release version of my SFML-Application is going to be created and create a makefile with the command „cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release ..“


10.   Then i compile the project with „mingw32-make“ and run the executable. It starts without issues.


11.   I go back to CMake and repeat step 5. But this time i set CMAKE_BUILD_TYPE to „Debug“ and click on generate


12.   I repeat Step 6, after compilation i have not only the release-libraries, but also the debug-libararies of SFML in „C:/SFML/libs“


13.   I copy the received dll-files (for example „sfml-graphics-d-2.dll) from C:/SFML/libs to the Destination-Folder where the debug version of my SFML-Application is going to be compiled. Here it is „D:\Nextcloud\C++\observer4\cmake-build-release“

14.   Then i create a makefile with the command „cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Debug ..“ and compile.
The Program runs fine.


15.   When i open my IDE Clion and run the program in release mode, it suddenly does not work anymore. The same applies when i try to start the release-version from CMD after i have tried to run it from Clion.


16. Now when i switch the content of the CMakeLists.txt file in "„D:\Nextcloud\C++\observer4\" from

cmake_minimum_required(VERSION 3.10)
project(observer4)
set(CMAKE_CXX_STANDARD 17)
set(SFML_DIR "C:/SFML")
find_package(SFML COMPONENTS graphics window system)
add_executable(observer4 main.cpp etc. etc.)
target_link_libraries(observer4 sfml-graphics)
 

to

cmake_minimum_required(VERSION 3.10)
project(observer4)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/modules)
set(SFML_ROOT "C:/SFML")
find_package(SFML COMPONENTS graphics window system)
include_directories(${SFML_INCLUDE_DIR})
add_executable(observer4 main.cpp etc. etc.)
target_link_libraries(observer4 ${SFML_LIBRARIES})

and compile everything again, the SFML-Application starts running from Clion and CMD.

15

General / Re: SFML 2.5 CMake configuration

« on: February 20, 2020, 07:52:29 pm »

My assumption is that since you're not specifying a CMAKE_BUILD_TYPE for your own CMake script, CMake is simply inferring the type based on the libraries it finds, which then leads to your build picking release libraries, if they are provided, but since you're not providing the release DLLs, it crashes. Once you do provide them, it runs fine.

I made a screenshot where you can see that although i set CMAKE_BUILD_TYPE to Release in CMD it still complains that sfml-graphics-d-2.dll is missing. This happens only when the last compilation of the sfml-source-code in "C:/SFML" is done in debug-mode to create the debug-libraries in C:/SFML.

The same applies the other way around: When the last compilation of the SFML-Source to C:/SFML is done in release-mode, the debug-compilation of my SFML-Application will only accept release-dll-files regardless if the CMAKE_BUILD_TYPE is set to Debug. 

When i change the CMakeLists.txt of the SFML-Program to FindSFML.cmake the compiled release-executable in the cmake-build-release-folder works fine with the release-dll-files in the same folder. Same goes for the debug-version in cmake-build-debug-folder with the corresponding debug-dll-files.

EDIT: You may need to open the attached Screenshot in a new Window to see the whole picture because of its size & thanks for the fast reply btw.