Static SFML Project using CMake, 'No rule to make target lib/libglew32.a'?

[jabza]

Hi,

I'm trying to create a CMakeLists.txt file from scratch for my project. I've compiled the most recent SFML2 source as static libraries. However when building the file I get the following:

mingw32-make.exe[3]: *** No rule to make target 'C:/SFML-2.1/lib/libglew32.a', needed by 'Corruption.exe'.  Stop.

My CMakeLists.txt can be seen here: http://pastebin.com/CguyS83F
I've copied the most recent FindSFML.cmake file into my CMake Modules folder, and have followed the linking statically guide. I'm linking the SFML_DEPENDENCIES too.

Any idea as to why I'm getting this? Thanks for the help.

[eXpl0it3r]

It can't seem to find glew. Make sure the extlibs/subdir is in the linker path

[jabza]

Thanks for the reply.

Adding extlibs didn't seem to do much. Renaming lib/libglew.a to libglew32.a got rid of that error but presented me with these new ones:

C:\SFML-2.1\lib\libsfml-window-s-d.a(JoystickImpl.cpp.obj): In function `ZN2sf4priv12JoystickImpl10initializeEv':
C:/Users/Tom/Downloads/SFML-master/SFML-master/src/SFML/Window/Win32/JoystickImpl.cpp:71: undefined reference to `joyGetPosEx@8'
C:\SFML-2.1\lib\libglew32.a(glew.c.o):glew.c:(.text+0x152f0): undefined reference to `wglGetCurrentDC@0'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\SFML-2.1\lib\libglew32.a(glew.c.o): bad reloc address 0xf554 in section `.rdata'

I built the static libraries with the latest version from the repository, could this be the issue? I'm confused here because I'm trying to build just 32-bit, yet the glew lib inside extlib x64 is appended with 32. Surely that should be in the extlib x86? I wonder why it is therefore trying to use libglew32 (which is 64bit according to the above).

[zsbzsb]

https://github.com/SFML/SFML/wiki/FAQ#build-link-static

[jabza]

Thanks, I've already read through that. I'm also following the FindSFML.cmake instructions for linking statically, which I assume should address the dependency issue?

set(SFML_STATIC_LIBRARIES TRUE)
find_package(SFML 2 COMPONENTS system window graphics audio REQUIRED)

if(SFML_FOUND)
    include_directories(${SFML_INCLUDE_DIR})
    target_link_libraries(${EXECUTABLE_NAME} ${SFML_DEPENDENCIES})
    target_link_libraries(${EXECUTABLE_NAME} ${SFML_LIBRARIES})
endif()

I'm using the main.cpp basic example and have SFML_STATIC defined. I'm using an EAP of Jetbrain's C++ IDE so there is a chance something there is causing issue. But I doubt it since it's just running CMake in the background.

[zsbzsb]

I'm also following the FindSFML.cmake instructions for linking statically, which I assume should address the dependency issue?

Apparently you didn't read it, or failed to follow the simple instructions.

In the past SFML included on Windows all its dependencies into the SFML libraries. ... one needs to link SFML's dependencies on your own

AKA CMake will not longer add the dependencies that SFML relies on when building/linking statically.

[jabza]

Hmm... I thought that's why it says in the FindSFML file,

# Since you have to link yourself all the SFML dependencies when you link it statically, the following
# additional variables are defined: SFML_XXX_DEPENDENCIES and SFML_DEPENDENCIES (see their detailed
# description below).

# - SFML_DEPENDENCIES: the list of libraries SFML depends on, in case of static linking

Which is why I'm setting:

target_link_libraries(${EXECUTABLE_NAME} ${SFML_LIBRARIES})
target_link_libraries(${EXECUTABLE_NAME} ${SFML_DEPENDENCIES})

So this is redundant now? Sorry if I misunderstood you. I'm a CMake noob, I think I'm using the SFML_DEPENDENCIES variable incorrectly.

[Laurent]

No, you did everything correctly, don't worry.

Try to find which system libraries the missing functions belong to, and add them to the linked libraries. This may be a bug in FindSFML.cmake (it's new and has not been tested a lot).

[jabza]

Thanks, good to know. So what I've found is that if I rename libglew.a to libglew32.a the error goes away but I start to get a bunch of these errors:

C:\SFML-2.1\lib\libsfml-window-s-d.a(Window.cpp.obj): In function `ZN2sf6WindowC2Ev':
C:/Users/Tom/Downloads/SFML-master/SFML-master/src/SFML/Window/Window.cpp:48: undefined reference to `sf::Clock::Clock()'

I have similar errors for, libsfml-window-s-d and libsfml-graphics-s-d. There's a bunch of undefined references for

__glewXXXXXX  

I'm going to try compiling my own extlibs rather than using 'C:\Users\Tom\Downloads\SFML-master\SFML-master\extlibs\libs-mingw' as my mingw version may be different. Also, is it a bug that libglew32.a is inside x64 and libglew.a is inside x86?

As you say, I am using the most recent snapshot from the repo. Here's the entire log: http://pastebin.com/CgthCdQB Thanks for the help.

[Laurent]

I have similar errors for, libsfml-window-s-d and libsfml-graphics-s-d.

The link order is wrong. Read the tutorial to know more about the linking order of dependent libraries (basically, you must use the reverse order). In case you wonder, the order of SFML libraries is given by the list of components that you give to find_package(SFML ...).

There's a bunch of undefined references for
__glewXXXXXX

It's not supposed to happen. And you shouldn't have to rename libglew.a, it can find both libglew and libglew32.

I'm going to try compiling my own extlibs rather than using 'C:\Users\Tom\Downloads\SFML-master\SFML-master\extlibs\libs-mingw' as my mingw version may be different.

It should not make a difference. There are less incompatibilities between compiler versions when you deal with C libraries. That's why SFML dependencies are compiled once for all MSVC versions, and once for all gcc versions.

Also, is it a bug that libglew32.a is inside x64 and libglew.a is inside x86?

It doesn't make any difference, but yes, it would be better if we used consistent names.

Here's the entire log

You should link the SFML dependencies after the SFML libraries themselves. It's not clear what you do since you've posted both orders.

[jabza]

Thanks, linking the way you suggested has got me down to one error. I'm now doing the following:

find_package(SFML 2 COMPONENTS graphics window audio system REQUIRED)

target_link_libraries(${EXECUTABLE_NAME} ${SFML_LIBRARIES})
target_link_libraries(${EXECUTABLE_NAME} ${SFML_DEPENDENCIES})

The error I'm getting is still to do with libglew,

C:\SFML-2.1\lib\libglew32.a(glew.c.o):glew.c:(.text+0x15262): undefined reference to `wglGetCurrentDC@0'
C:\SFML-2.1\lib\libglew32.a(glew.c.o):glew.c:(.text+0x152f0): undefined reference to `wglGetCurrentDC@0'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\SFML-2.1\lib\libglew32.a(glew.c.o): bad reloc address 0xf554 in section `.rdata'

If I don't rename the x86 build to libglew32.a I get the error, libglew32.a not found.

[Laurent]

Line 274 of FindSFML.cmake:

set(SFML_DEPENDENCIES ${SFML_DEPENDENCIES} ${SFML_GRAPHICS_DEPENDENCIES})
 

Try this instead:

set(SFML_DEPENDENCIES ${SFML_GRAPHICS_DEPENDENCIES} ${SFML_DEPENDENCIES})
 

[jabza]

That did the trick. Really appreciate it, was pulling my hair out trying to fix it. Now I can build my project using CMake.

[Laurent]

Great, I've fixed it in the repository.

Thanks for your patience