SFML with Thor in Fedora 27 Codeblocks - g++

Im trying to start a simple game with SFML 2.4 and Thor 2.0 using Code Blocks in C++.
Im linking dynamically the libraries.
For the Release option on Linker settings tab
sfml-audio
sfml-graphics
sfml-window
sfml-system
thor
In Search directories -> Compiler:
/usr/include
In Search directories -> Linker:
/usr/lib
The game compile well but throw some warnings:
||warning: libsfml-graphics.so.2.3, needed by /usr/lib/libthor.so, not found (try using -rpath or -rpath-link)|
||warning: libsfml-window.so.2.3, needed by /usr/lib/libthor.so, not found (try using -rpath or -rpath-link)|
||warning: libsfml-system.so.2.3, needed by /usr/lib/libthor.so, not found (try using -rpath or -rpath-link)|
When I run it a window open that says:
error while loading shared libraries: libsfml-graphics.so.2.3: cannot open shared object file: No such file or directory
I supose that Thor is searching an old verison of SFML. Any idea how could i correct that?
Note: in /usr/lib/ are there all the libsfml files with the extension 2.4.2 and 2.4 in some cases. Not 2.3

The version of Thor you're using is compiled to be used with SFML 2.3, not 2.4. You'll either need to grab the Thor source from here and compile it your self, or get the SFML 2.3 libraries.

Related

Error using SDL2, SDL2_image with Cmake CLion on Windows [duplicate]

I'm trying to install SDL on MinGW.
I've downloaded SDL from here (the SDL2-devel-2.0.0-mingw.tar.gz link), then copied the contents of SDL2-2.0.0/x86_64-w64-mingw32/{bin,include,lib} into the matching directories in my MinGW installation.
When I try to compile any file that contains #include ‹SDL2/SDL.h› using gcc test.c -lmingw32 -lSDL2main -lSDL2 -mwindows, GCC complains about undefined reference to WinMain#16 and undefined reference to some SDL functions.
SDL2-devel-2.0.0-mingw.tar.gz contains both 32-bit libraries (i686-w64-mingw32 directory) and 64-bit libraries (x86_64-w64-mingw32 directory).
The error was caused by using a 64-bit version of the library with a 32-bit compiler.

Cmake errors when using LLVM 5.0.0 from brew

I'm trying to use the stock LLVM 5.0.0 provided by Homebrew (MacOS High Sierra 10.13.3). LLVM is installed on my machine under /usr/local/Cellar/llvm/5.0.0/
Now, in my project, I have the following lines in CMakeLists.txt:
# Find the LLVM library
find_package( LLVM 5.0.0 REQUIRED )
include_directories( "${LLVM_INCLUDE_DIRS}" )
link_directories(${LLVM_LIBRARY_DIRS})
message(STATUS "LLVM include dirs: ${LLVM_INCLUDE_DIRS}")
If I run CMake without any parameters, I get:
CMake Error at CMakeLists.txt:74 (find_package):
By not providing "FindLLVM.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "LLVM", but
CMake did not find one.
Could not find a package configuration file provided by "LLVM" (requested
version 5.0.0) with any of the following names:
LLVMConfig.cmake
llvm-config.cmake
Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
"LLVM_DIR" to a directory containing one of the above files. If "LLVM"
provides a separate development package or SDK, be sure it has been
installed.
It tells me that it couldn't find LLVM. So, I pass the path to the LLVM_DIR, like this:
cmake .. -DLLVM_DIR=/usr/local/Cellar/llvm/5.0.0/share/cmake/modules/
I would expect everything to work. Instead I get the following error:
CMake Error at CMakeLists.txt:74 (find_package):
Could not find a configuration file for package "LLVM" that is compatible
with requested version "5.0.0".
The following configuration files were considered but not accepted:
/usr/local/Cellar/llvm/5.0.0/share/cmake/modules/llvm-config.cmake,
version: unknown
For some reason the version is not present anywhere in the share/cmake/modules directory.
How can I fix this, without changing the brew-installed LLVM?
Found the answer. I was passing a wrong path to LLVM_DIR.
I just have to use another directory (buried in lib, not in share):
cmake .. -DLLVM_DIR=/usr/local/Cellar/llvm/5.0.0/lib/cmake/llvm/
Not sure why brew decided to install 2 versions of CMake helpers for LLVM, one in share and one in lib.

No FindVTK module in CMake

When I am trying to compile an open-source package which uses VTK, I get this error in CMake:
include could not find load file:
/Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindVTK.cmake
I looked in the path mentioned and there is indeed no FindVTK module. I think I compiled VTK successfully on the same machine, but now I have my doubts.
Isn't the FindVTK.cmake module meant to ship with CMake?
Is this module meant to appear after compilation of VTk source code?
FindVTK.cmake was removed in CMake 3.1. It exists in versions prior to CMake 3.1.
FindVTK.cmake documentation
The CMake documentation is pretty clear on this
FindVTK
This module no longer exists.
This module existed in versions of CMake prior to 3.1, but became only
a thin wrapper around find_package(VTK NO_MODULE) to provide
compatibility for projects using long-outdated conventions. Now
find_package(VTK) will search for VTKConfig.cmake directly.
Source:
https://cmake.org/cmake/help/v3.4/module/FindVTK.html

Xcode 5 how to Linking Dynamic Libraries from App Bundle

I want to distribute some libraries in to my OS X application bundle, last two days i am working on this however couldn't make it. until now what i did.
with using install name tool i have fixed library paths. additionally in time i have tried #loader_path/../Libraries and #executable_path/../Libraries as well.
otool -L libMagickWand-6.Q16.2.dylib
#rpath/../Libraries/libMagickWand-6.Q16.2.dylib (compatibility version 3.0.0, current version 3.0.0)
#rpath/../Libraries/libMagickCore-6.Q16.2.dylib (compatibility version 3.0.0, current version 3.0.0)
#rpath/../Libraries/libfreetype.6.dylib (compatibility version 18.0.0, current version 18.2.0)
#rpath/../Libraries/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
#rpath/../Libraries/libz.1.2.5.dylib (compatibility version 1.0.0, current version 1.2.5)
#rpath/../Libraries/libltdl.7.dylib (compatibility version 11.0.0, current version 11.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
in project targets / Build Phases / Add New Build Phase / Add Copy Files build Phase and copied all dynamic libraries to my app bundle.
that worked well, I can see the libraries are in the app bundle.
then adding #rpath/../Libraries/ to Build Settings / Runpath Search Paths
but still getting error message..
ld: library not found for -lMagickWand-6.Q16.2 clang: error: linker
command failed with exit code 1 (use -v to see invocation)
if i add direct path lets say libraries are located in /User/username/libs/ to Library Search Paths in build settings it works.
am i missing something?
Content/Libraries is not a standard directory within an app bundle; use Contents/Frameworks instead (.dylibs are allowed in that directory just the same as .frameworks).
Set the Install Name of each library to #rpath/libWhatever.dylib and set the Runpath Search Path of the executable (in Contents/MacOS) to #loader_path/../Frameworks.
For library interdependencies then Runpath Search Path will need to be simply #loader_path so dependent libraries can be loaded from the same directory.
EDIT: People might find the copy_dylibs.py script in this repo useful for copying third-party .dylibs into the App Bundle. It recursively hunts for libraries that need copying and corrects the Install Name of the libraries as well as code-signing them.

Linking libraries using CMake and PkgConfig

I am trying to link a static library (GLFW) to my own library that I am building. I have the following in my CMakeLists.txt file in order to do this:
pkg_search_module(GLFW REQUIRED glfw3)
include_directories(${GLFW_INCLUDE_DIRS})
target_link_libraries(${LIBRARY_NAME} ${GLFW_STATIC_LIBRARIES})
When linking my library, I get the following error: ld: library not found for -lglfw3
Yet, running pkg-config --libs glfw3 in the console gives:
-L/usr/local/lib -lglfw3
So I know that the GLFW library is installed. Why isn't the library being found when I try linking using CMake?
I got the same error when using the argument -lglfw3, and after much trial and error I found I needed to use -lglfw.3
You're adding the library name but not the the linker search path. Try:
link_directories(${GLFW_LIBRARY_DIRS})