Static Linking Examples

[Garph]

Hey All,

I am building SFML from source, on Windows using CMake, Ninja and Clang. Here are my toolchain's versions (from cmd):

$ cmake -version
cmake version 3.17.0-rc1

$ clang --version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: i686-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\bin

$ ninja --version
1.8.2

My project's root has a SFML directory, a build directory (for cmake output) and a CMakeLists.txt

cmake_minimum_required (VERSION 3.17)
project (game C CXX)

set (CMAKE_C_COMPILER "clang")
set (CMAKE_CXX_COMPILER "clang++")

add_subdirectory (SFML)

I configure the project as follows:

$ cmake .. -G Ninja -DBUILD_SHARED_LIBS=FALSE -DSFML_BUILD_EXAMPLES=TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/mattp/source/game/build


And build:

ninja -j all

However, when launching build/SFML/examples/pong/pong-d.exe I fail to link with OpenAl32.dll. It seems I'm missing something here. Coming from the embedded devices world, I'm very new to dynamic linking and would appreciate some guidance.

[Garph]

Oof, just found https://github.com/SFML/SFML/blob/master/cmake/SFMLConfig.cmake.in

I'll update with results should this work

[Garph]

Here is what works:

Project CMakeLists.txt

(click to show/hide)

cmake_minimum_required (VERSION 3.17)

project (games VERSION 0.0.1)

set(CMAKE_C_COMPILER "clang.exe")
set(CMAKE_CXX_COMPILER "clang++.exe")

add_subdirectory (SFML)
add_subdirectory (hello-world)

hello-sfml CMakeLists.txt

(click to show/hide)

add_executable (hello-sfml hello-sfml.cpp)

target_link_libraries (hello-sfml
    sfml-system
    sfml-window
    sfml-graphics
)

Building from command line:

(click to show/hide)

$ cmake .. -DCMAKE_BUILD_TYPE=DEBUG -DEXPORT_COMPILE_COMMANDS=ON -DBUILD_SHARED_LIBS=OFF -G Ninja
$ ninja hello-sfml

[Laurent]

It's a little confusing.

First you mention a problem with OpenAL32.dll, which is a SFML dependency that cannot be linked statically (because of its license), there's nothing you can do about it (*). This also means that you link to sfml-audio.

Then you talk about SFMLConfig.cmake, which you do not use since you compile SFML as part of your own sources (SFMLConfig.cmake is used to find a pre-compiled SFML release, through a call to find_package). "Should this work" -> but what? You never say what you intend to do with it.

And finally you show something that "works", but you don't explain anything, all we see is that you don't link to sfml-audio anymore so you hide the OpenAL32.dll "issue" you had in first place.

(*) In fact there is, but let's keep things simple