I have been trying to use SFML in a CMake project, specifically the header SFML/Audio.hpp. I installed SMFL using Homebrew, and both the .dylib-files and the headers should be located correctly, in /usr/local/lib and /usr/local/include, respectively.
Now running CMake works fine, telling me that it has Found SFML 2.4.2 in /usr/local/include.
However, when compiling the project (using make), I get the following error:
/path/to/project.hpp:12:10: fatal error: 'SFML/Audio.hpp' file not found.
Does anyone know why this is happening?
Note: Compiling works fine for colleagues of mine using the same CMake- and source files on various Linux operating systems.
This sounds like you simply forgot to add SFML's include directory. On Linux, they probably install SFML to some system path where GCC (or Clang) look by default, so they don't need any additional CMake directives.
Luckily, fixing this is pretty simple.
Add the following line to your CMakeLists.txt somewhere before defining targets:
include_directories(${SFML_INCLUDE_DIR})
The variable SFML_INCLUDE_DIR is populated when you successfully call find_package(SFML...).
While you're at it, you might also want to ensure to link to the proper library files in the correct order:
target_link_libraries(myTargetName ${SFML_LIBRARIES} ${SFML_DEPENDENCIES})
Again, both variables are populated automatically.
Related
I have a project where I want to use etcd-cpp-apiv3 library(https://github.com/etcd-cpp-apiv3/etcd-cpp-apiv3), so I installed with vcpkg. But when I run it, fails.
I installed it with vcpkg: 'vcpkg install etcd-cpp-apiv3:x64-windows' and included it with these cmake commands:
set(VCPKG_ROOT "C:/vcpkg")
set(VCPKG_TARGET_TRIPLET "x64-windows")
set(CMAKE_TOOLCHAIN_FILE "C:/vcpkg/scripts/buildsystems/vcpkg.cmake")
set(CMAKE_PREFIX_PATH "${VCPKG_ROOT}/installed/x64-windows")
include_directories(${CMAKE_PREFIX_PATH}/include)
find_package(etcd-cpp-api CONFIG REQUIRED)
target_link_libraries(${PROJECT_NAME} PRIVATE etcd-cpp-api)
It recognizes the include statement: #include <etcd/Client.hpp> But when I run the project I get so many errors on pplx header files located in vcpkg installation folder: C:/vcpkg/installed/x64-windows/include/pplx Examples of these errors
C:/vcpkg/installed/x64-windows/include/pplx/pplxtasks.h:2877:21: error: '_ASSERTE' was not declared in this scopeIn main
C:/vcpkg/installed/x64-windows/include/pplx/pplxtasks.h:222:104: note: in definition of macro 'PPLX_CAPTURE_CALLSTACK' 222 | #define PPLX_CAPTURE_CALLSTACK() ::pplx::details::_TaskCreationCallstack::_CaptureSingleFrameCallstack(_ReturnAddress())
C:/vcpkg/installed/x64-windows/include/pplx/pplxtasks.h: In instantiation of 'pplx::details::_Task_completion_event_impl<_ResultType>::~_Task_completion_event_impl() [with _ResultType = unsigned char]':
Apparently the library uses pplx
I have tried to add manually pplx library with target_include_libraries but I dont know if that makes any sense. I have also tried to remove output cmake folder, reinstall all vcpkg, make sure the the vcpkg paths and environtment variables are set up correctly, make sure that I was dowloading x64 bits libraries etc but none worked.
Im using windows 64 bit, with clion.
If someone could help me or give a clue about what is going on, I would be very pleased
I found the error.
Etcd-clientv3 library uses cpprest library which only supports Microsoft's C++ compiler, MSVC. As I was using Clion's default compiler, Mingw, there were lot of errors when compiling cpprest.
The solution was to change clion's compiler to MSVC
I have the following fftw3 header files under /usr/local/include:
Further, I have the following fftw3 static libraries under /usr/local/lib:
However, when I try to compile my file using cmake and running make afterwards, I get the following errors:
What I find particularly odd is that when compiling the individual *.cpp files, I get no error despite the fact that these files use fftw_malloc and other functionality from fftw3.h.
I'm using gcc and g++ version 10.2.0. I configure my CMake file using cmake -DCMAKE_CXX_COMPILER=g++-10 -DCMAKE_C_COMPILER=gcc-10.
I configured fftw3 through the download on the fftw3 website and running ./configure, make, sudo make install in that order. As mentioned before, the files seem to have been installed in the correct place. I also tried the same with homebrew and MacPorts and ended up with the same result.
I'm also using findFFTW. Without this, even the *.cpp files don't seem to compile properly. Further, even findFFTW claims to have found the FFTW3 library, giving the following output during the configuration of the make file:
-- Found FFTW: /usr/local/include
Finally, my target link libraries are set to the following in the CMake file:
target_link_libraries(cartogram CGAL::CGAL Boost::program_options fftw3)
Is there any way I can solve the error I get? (ld: library not found for -lfftw3)
Edit: On a side note, the exact same cmake file works perfectly find on Ubuntu, Linux!
When using CMake on unix I dont have any issues. I can use CLion to do a cmake setup, cmake build and cmake install, open a different project and it will find the previously built library when using find_package. On windows this does not seem to be possible. By default it tries to install the build code into strange directories (like C:\Program Files). I have added a CMAKE_INSTALL_PREFIX to both my library CMakeLists.txt and the appliation CMakeLists.txt, however when using find_package(SDL2)CMake still complains there is no config file for CMake and SDL2. When checking the following file exists:
U:\various\cmake-cache\Program Files (x86)\SDL2\cmake\SDL2Config.cmake
The directory U:\various\cmake-cache was used as CMAKE_INSTALL_PREFIX for both SDL2 and my application. Yet it still refuses to compile.
What can I do to make CMake at least somewhat useful on windows? On Unix things work great, but it feels like a huge PITA on Windows so far... It seems like all the concepts dont work there. I would really like to have one central location that is used by every CMake build on my system and everything is installed there and when another project uses a library it is searched there. Is this possible?
Using OSX and vim...
Downloaded SDL2 from the website, then moved the SDL2.framework into /Library/Frameworks/
Using tutorial code, and Makefile... SDL.h is not found.
Makefile: g++sdl-config --cflags --libssdltest.cpp -o sdltest
I've read numerous things about pointing the compiler to the framework, but everything I've tried doesn't seem to work, and I thought /Library/Frameworks/ was the default area for the compiler to look
Got it to work.
Getting this to work took multiple tries, but the root of the issue for each try was that most of the Tutorials I was looking at were for SDL1.2 when I was using SDL2.
This changed flags in the make file, directories to search in and other things. Interestingly, I could never get the compiler to see SDL.h when it was in the /Library/Frameworks/ directory. However using Macports to install SDL2 allowed me to point the compiler to where Macports installed SDL2 header files - /opt/local/include/SDL2
That seems to have done it for me
Thank you for your question, because I was having similar difficulties! There seems to be a dearth of detailed and helpful tutorials on how to install SDL2 using Macports.
I got it working! Here are the steps:
Visit this link to find the Macports package appropriate for your version of Mac OS X. Install the version you need, and once that is done, proceed to step 2.
https://www.macports.org/install.php
After installation is done, visit this link to find the SDL2 port.
https://www.macports.org/ports.php?by=name&substr=libsdl
The one I needed was the third from the top, called libsdl2. I will be providing the name for you so feel free to visit the link simply for your own edification.
Open the Terminal, and type sudo port install libsdl2. If all goes to plan, you should see it installing and updating. Once it is complete, you should have a functional installation of the SDL2 Header files, (ending in .h), Static Library files (ending in .a) and Dynamic Library files (which contain dylib). You may have to do some poking around in Finder to locate where it installed.
The advantage of this workaround is the ability to use SDL with other IDE's besides Xcode, Eclipse for instance. Whereas Xcode requires you to assign a path of /Library/Frameworks, this technique should allow you to use the IDE of your choosing.
The final step is going into your IDE and assigning the build paths to these newly installed and compiled SDL files. For instance, the paths for mine are /opt/local/include and /opt/local/lib. Be mindful of the fact that your path may differ from these, but these examples should give you an idea of where to look.
Hopefully this is helpful for somebody!
I have a project I'm writing that uses LuaJIT. I'm trying to run my project on a computer I have not run it on in a while. It used to run just fine but now when I try to run it it complains.
I have LuaJIT in my source tree, and it builds just fine. I'm using CMake to generate my make files, and as far as I can tell CMake finds the file libluajit.so, but when I run my program, I get the following error:
../build/game/game: error while loading shared libraries: libluajit-5.1.so.2: cannot open shared object file: No such file or directory
I don't know why it's looking for that version of the library instead of libluajit.so. This is Ubuntu linux for what it's worth. I can add more details if necessary, I can add more details if necessary, I'm not sure what info would be helpful to figure out happening.
Edit:
To build and link the program I have these lines in the file CMakeLists.txt (this is abbreviated a bit to just show the relevant bits)
find_package(LuaJIT REQUIRED)
set(Extern_LIBS luajit)
add_executable(proj ${proj_Sources})
target_link_libraries(proj ${Extern_LIBS})
After I run cmake on my source directory, I run make. Then to run it I just run ./proj
When you built it, the ".so" was actually a symlink to the library. Verisioned filenames and SONAMEs are used so that multiple versions of a library can coexist, preventing problems commonly found on... other operating systems whereby older software is incompatible with the newer library, and newer software is incompatible with the older library.