I fixed my static linking issues (and I don't know why)

[Zoodinger]

Hello,

After a very long time (much longer than I'd like to admit), I finally managed to statically link SFML statically with MinGW-w32 and CMake. Here's a minimal CMakeLists.txt file that makes it work:

cmake_minimum_required(VERSION 3.2)
set(PROJECT_NAME StaticSample)
set(EXECUTABLE_NAME ${PROJECT_NAME})

# Enable debug symbols by default
if(CMAKE_BUILD_TYPE STREQUAL "")
  set(CMAKE_BUILD_TYPE Debug)
endif()

# Statically link MinGW standard libraries
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static-libstdc++ -static-libgcc")

add_executable(${EXECUTABLE_NAME} main.cpp)

# Detect and add SFML
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake_modules" ${CMAKE_MODULE_PATH})

set(SFML_STATIC_LIBRARIES TRUE)

find_package(SFML 2 REQUIRED system window graphics network audio)
if(SFML_FOUND)
  include_directories(${SFML_INCLUDE_DIR})
  target_link_libraries(${EXECUTABLE_NAME} ${JPEG_LIBRARY} ${SFML_LIBRARIES} ${SFML_DEPENDENCIES})
endif()

# Install target
install(TARGETS ${EXECUTABLE_NAME} DESTINATION bin)

This also works with GLEW, with some additional steps: I included glew.c as part of the source code, added the required include dirs and set the -DGLEW_STATIC symbol (I find this more convenient than linking statically with the library). Everything seems to compile/link/run fine.

However, I don't understand why. Pretty much every resource I have seen does not say that I need to link against the jpeg library before sfml-system and the other dependencies. In fact, it seems it's always suggested for sfml-system to be linked first.

I feel like I need to understand what's really happening here, and whether or not I'm doing something wrong - i.e. I don't want to potentially deal with any other linking issues once I start using more SFML functionality.

[Jesper Juhl]

The order libraries (and object files) are linked in matters.
See for example:
http://stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause-errors-in-gcc
http://lampwww.epfl.ch/~fsalvi/docs/gcc/www.network-theory.co.uk/docs/gccintro/gccintro_17.html

[Zoodinger]

Thank you for your reply. I'm aware that the linking order matters. My puzzlement comes from why this particular order is the one that works, if it's not like other solutions I have seen. I'm also worried that some of the libraries are still in the wrong order, but I'm not getting any errors yet, since I'm not calling their methods. I suppose I'll know when that happens, and move them around until it works again