SFML community forums

Help => General => Topic started by: Garph on February 21, 2020, 06:27:32 pm

Title: Static Linking Examples
Post by: Garph on February 21, 2020, 06:27:32 pm
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.
Title: Re: Static Linking Examples
Post by: Garph on February 21, 2020, 06:29:51 pm
Oof, just found https://github.com/SFML/SFML/blob/master/cmake/SFMLConfig.cmake.in

I'll update with results should this work
Title: Re: Static Linking Examples
Post by: Garph on February 21, 2020, 08:12:43 pm
Here is what works:

Project CMakeLists.txt
(click to show/hide)

hello-sfml CMakeLists.txt
(click to show/hide)

Building from command line:
(click to show/hide)
Title: Re: Static Linking Examples
Post by: Laurent on February 21, 2020, 09:24:13 pm
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