Linking SDL2/SD2_image statically with CMake

Question

I'm trying to add SDL2 as a library to my project. I want to link it statically. I'm new to c++.

1 - Why does the SDL website recommend linking dynamically whenever possible?

I understand the benefits of dynamic libs. However, assuming users will have all the libraries you need already installed and ready to go in their system is a pretty big assumption IMO. The only case where linking dynamically sounds like a good idea to me is where you are using well know libraries that ship with the OS/platform. https://wiki.libsdl.org/Installation

2 - Linking dynamically seems to automatically find the intrinsic dependencies of (SDL2 and SDL2_image). Linking statically does not. Why is this the case? Here's my FindSDL2_image.cmake file

find_path(SDL2_IMAGE_INCLUDE_DIR SDL_image.h)
include_directories(${SDL2_IMAGE_INCLUDE_DIR})

# PREFER STATIC LIBRARIES ########
# cmake respects the order of extensions when looking for libraries
SET(CMAKE_FIND_LIBRARY_SUFFIXES .lib .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
# ------------------- ########

find_library(SDL2_IMAGE_LIBRARY NAMES SDL2_image PATH_SUFFIXES lib ${VC_LIB_PATH_SUFFIX})
set(SDL2_IMAGE ${SDL2_IMAGE_LIBRARY})

This links sdl2_image statically. It doesn't link properly because Undefined symbols:

  "_png_set_strip_16", referenced from:
      _IMG_LoadPNG_RW in libSDL2_image.a(IMG_png.o)
  "_png_set_write_fn", referenced from:
      _IMG_SavePNG_RW_libpng in libSDL2_image.a(IMG_png.o)
  "_png_write_png", referenced from:
      _IMG_SavePNG_RW_libpng in libSDL2_image.a(IMG_png.o)

If I remove the section ### PREFER STATIC LIBRARIES ## on the cmake file. It links dynamically and everything works as expected. Why when linking dynamically the intrinsic dependencies are resolved but not when linking statically?

----UPDATE----

I was able to link sdl2_image statically by including its dependencies explicitly

find_library(PNGLIB png)
find_library(JPEG jpeg)
find_library(TIFF tiff)
find_library(WEBP webp)
find_library(LZ z)

target_link_libraries(smb ${SDL2} ${PNGLIB} ${JPEG} ${TIFF} ${WEBP} ${SDL2_IMAGE} ${LZ})

However, this will not scale well for me. Figuring out what these dependencies took a bit of guesswork and googling. Ideally, I'd like CMAKE to pull these in automatically.

Answer 1

it looks like there are several questions, I'll try my best to answer the question step by step:

Why does the SDL website recommend linking dynamically whenever possible

One of the reason to link you application dynamically against a library is to decouple the application from the library (it is called shared library / .so in this case). You could update your library without the necessity of recompiling your application code. E.g. in case you have finished your project, and your client have your application running, I suppose, it is not likely that you want to recompile your application code, once there is a bug fix of the underlying library you are using.

On the other side, by linking your application statically, you're binding your application with that library (.lib or .a form). Means every changes in the library will cause you to recompile your code. Sometime this is wished, e.g. you have provide your client a warranty of your application, usually you want to be sure that no future problem with your library would cause your application to be crashed.

I have a short example code to understand this better: CMakeLists.txt:

cmake_minimum_required (VERSION 3.0)
project(linkageLibrary)

set(STATIC_LIB lib_static)
set(SHARE_LIB lib_share)

set(STATIC_OTHER_LIB lib_otherstatic)
set(SHARE_OTHER_LIB lib_othershare)


add_library(${STATIC_LIB} STATIC ${STATIC_LIB}.cpp)
add_library(${SHARE_LIB} SHARED ${SHARE_LIB}.cpp)

# not yet in usage...
add_library(${STATIC_OTHER_LIB} STATIC ${STATIC_OTHER_LIB}.cpp)
add_library(${SHARE_OTHER_LIB} SHARED ${SHARE_OTHER_LIB}.cpp)

add_executable(${CMAKE_PROJECT_NAME} main.cpp)
target_include_directories(${CMAKE_PROJECT_NAME} PUBLIC ${${CMAKE_PROJECT_NAME}_SOURCE_DIR})
target_link_libraries(${CMAKE_PROJECT_NAME} ${STATIC_LIB} ${SHARE_LIB})

file(WRITE ${CMAKE_BINARY_DIR}/exchangeShareLibrary.sh "
 echo \"before exchange the static library\"
 ${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME} &&
 mv ${CMAKE_BINARY_DIR}/lib${SHARE_LIB}.so ${CMAKE_BINARY_DIR}/lib${SHARE_LIB}.so.bk &&
 cp ${CMAKE_BINARY_DIR}/lib${SHARE_OTHER_LIB}.so ${CMAKE_BINARY_DIR}/lib${SHARE_LIB}.so &&
 echo \"after the shared library has been changed\" &&
 ${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}")

file(WRITE ${CMAKE_BINARY_DIR}/exchangeStaticLibrary.sh "
 echo \"before exchange the static library\"
 ${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME} &&
 mv ${CMAKE_BINARY_DIR}/lib${STATIC_LIB}.a ${CMAKE_BINARY_DIR}/lib${STATIC_LIB}a.bk &&
 cp ${CMAKE_BINARY_DIR}/lib${STATIC_OTHER_LIB}.a ${CMAKE_BINARY_DIR}/lib${STATIC_LIB}.a &&
 echo \"after the static library has been changed\" &&
 ${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}")

main.cpp:

#include <iostream>
#include "lib.hpp"
using namespace std;

int main() {
    printStaticLib();
    printShareLib();
    return 0;
}

lib.hpp:

#pragma ONCE

void printStaticLib();
void printShareLib();

lib_static.cpp:

#include <iostream>
#include "lib.hpp"
using namespace std;

void printStaticLib() {
    cout << "linkage of lib_static" << endl;
}

lib_share.cpp:

#include <iostream>
#include "lib.hpp"
using namespace std;

void printShareLib() {
    cout << "linkage of lib_share" << endl;
}

lib_otherstatic.cpp:

#include <iostream>
#include "lib.hpp"
using namespace std;

void printStaticLib() {
    cout << "linkage of the other lib_static with other text" << endl;
}

lib_othershare.cpp:

#include <iostream>
#include "lib.hpp"
using namespace std;

void printShareLib() {
    cout << "linkage of the other lib_share with other text" << endl;
}

if you run the generated scripts, you'll notice the printShareLib() will output differently after the .so get exchange, but not the printStaticLib(). (Try to make again without clean-up, if you now execute ./linkageLibrary, you'll get this time also other output for the printStaticLib(). Can you guess why?)

to your second issue:

2 - Linking dynamically seems to automatically find the intrinsic dependencies of (SDL2 and SDL2_image). Linking statically does not. Why is this the case?

without knowing your system setup, I guess the .a static library couldn't be found by your build system. Try to find where it is, and eventually put find_library(SDL2_IMAGE_LIBRARY NAMES SDL2_image HINTS ${_YOUR_SDL2_INSTALLATION_PATH})link

now back to your question, why SDL2 suggested to be linked dynamically, well it is the decision of the library developer, as you could read in his README

Please also refer this blog of how using SDL2 with CMake

Answer 2

A Static library is merely a collection of compiled object files. It does not have any additional information about its dependent libraries. You can use the ar -t &ltstatic_lib&gt command to view the contents of a static library. So if you need to link your executable to a static library, you have to provide the names and paths of all its dependent libraries.

For example: Consider two static libs, A and B and assume that A depends on B. Then if want your exe C to link to A, then your link statement should contain both A and B. Then only all the symbols will defined properly.
Linker: C ===> A and B

A dynamic library is different and more intelligent than a static. It is of ELF format and it's headers have information about its dependent shared libraries. This can be viewed by issuing the ldd &ltdynamic_lib&gt command on it. Also dynamic loader knows at runtime to pick the dependent libraries from the standard locations. If it can't find, it will give an error. In your case, you will find the information about the dependent libraries of your dynamic library in your ldd output and presumably, all those libraries will be in a standard location. That is the reason you are not finding an error, when you are trying to dynamically link.

Here are some useful links to know more about this,
https://renenyffenegger.ch/notes/development/dynamic-loader
https://amir.rachum.com/blog/2016/09/17/shared-libraries/

Answer 3

When you do a find_package in CMake will search for a Findxxx.cmake file in some CMAKE-defined paths.

The command has two modes by which it searches for packages: “Module” mode and “Config” mode. Module mode is available when the command is invoked with the above reduced signature. CMake searches for a file called Find.cmake in the CMAKE_MODULE_PATH followed by the CMake installation.

(https://cmake.org/cmake/help/latest/command/find_package.html)

So you have to define your own FindSDL2.cmake which will tell where is the library. (https://cmake.org/cmake/help/v3.17/manual/cmake-developer.7.html)

And you need to say to find_package to search for your own FindSDL2.cmake. You can pass a path to find_package to perform this.

If you make CMake use your file, the variables ${SDL2_INCLUDE_DIRS} and ${SDL2_LIBRARIES} you will be the one you have defined in your file.

Answer 4

A couple of possibilities here ..

The easiest explanation is that you have a dynamic libpng.so.x installed somewhere where your dynamic linker can find it (/usr/lib, /usr/local/lib, etc), but don't have a static libpng.a. The answer in that case would be to install a static libpng.a and see if cmake's magic can resolve it.

The next easiest explanation is that there is no libpng.* on your system and there is some dynamic late binding going on. This can happen if, for instance, the software that you are building is also building libpng.* in which case the late binding will allow you to successfully dynamically link your application to it, even though libpng actually has not yet been installed in /usr/lib or /usr/local/lib or wherever the software you are building will eventually put it. This is sort of a chicken-and-egg situation. You can figure this out by issuing "ldd foo" where "foo" is the name of your application. The output will be a grocery list of all the things the dynamic linker needs to fetch for your executable, libpng should be in the list and there should be a resolved path listed for it, if not it's possible that your application may start but subsequently crash if for instance png_write_png() is at some point invoked. How to workaround this would be to install the libpng.* libraries that your application is expecting, prior to building.

Hope this helps a bit :)