CMake, GLFW3 OSX linking error - c++

I've struggled for a while now linking GLFW libraries in my simple C++ project in CLion. I've gone through the existing problems and their solutions but they do not seem to help in my case. My CMakeLists file is as follows:
cmake_minimum_required(VERSION 3.6)
project(TestGame)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++14 -v")
find_library(carbon_lib Carbon)
find_library(cocoa_lib Cocoa)
find_library(iokit_lib IOKit)
find_library(corevideo_lib CoreVideo)
find_library(opengl_lib OpenGL)
find_library(corefoundation_lib CoreFoundation)
set(frameworks
${carbon_lib}
${cocoa_lib}
${iokit_lib}
${corevideo_lib}
${opengl_lib}
${corefoundation_lib}
)
file(GLOB sources
"include/*.hpp"
"src/*.cpp"
"src/application/*.cpp"
"src/controlling/*.cpp"
"src/helper/*.cpp"
"src/render/*.cpp"
"src/texturing/*.cpp"
"src/translations/*.cpp"
"test/*.cpp"
)
find_package(GLEW REQUIRED)
find_package(GLFW3 REQUIRED)
find_package(SDL2 REQUIRED)
find_package(GLM REQUIRED)
find_package(SOIL REQUIRED)
include_directories(${GLEW_INCLUDE_DIRS} ${GLFW_INCLUDE_DIR} ${GLM_INCLUDE_DIR} ${SDL2_INCLUDE_DIR} ${SOIL_INCLUDE_DIRS} ${GLM_INCLUDE_DIRS})
add_executable(GameMain ${sources})
target_link_libraries(GameMain ${GLEW_LIBRARIES} ${GLFW_LIBRARIES} ${GLM_LIBRARIES} ${SDL2_LIBRARY} ${SOIL_LIBRARIES} ${frameworks})
I've got GLFW3 and GLFW2 (apparently v2 was required by Cocoa and I have no idea why) installed using brew (brew install glfw2 or brew install glfw3 - with --build-bottle --static it does not work because of internal cmake error), also tried the same with manually compiled GLFW from the latest sources.
It is to be noticed that I've recently started learning things about C++/CMake/CLion so I might forget about something important in here - do not hesitate to ask for more informations so I can add these.
It is also worth noticing that before Sierra OSX (currently running latest BETA) update my application just ran quite fine without linker errors. Linker errors are as follows:
Undefined symbols for architecture x86_64:
"_glfwCreateWindow", referenced from:
Application::Application(char const*, int, int) in Application.cpp.o
"_glfwMakeContextCurrent", referenced from:
Application::Application(char const*, int, int) in Application.cpp.o
"_glfwWindowHint", referenced from:
Application::Application(char const*, int, int) in Application.cpp.o
"_glfwWindowShouldClose", referenced from:
Application::run() in Application.cpp.o
and these relates to main entry files where a window is created. CLion does not make any suggestion about anything being omitted while including directories. I tried with/without all these frameworks listed about, found a solution where Cocoa/IOKit/CoreVideo/OpenGL are to be included in order to make GLFW3 working. Tries also including Carbon/CoreFoundation because some solutions were about these.
Literally nothing works.

http://www.glfw.org/docs/latest/build_guide.html#build_link_cmake_package
You need to add:
target_link_libraries(LearnGLSL ..any other libraries... glfw)

Related

VkPipelineInfoEXT does not exist

I was recently following a tutorial for Vulkan called vkguide.dev.
I was on Chapter 1 part 2 called Vulkan Intialization Code(https://vkguide.dev/docs/chapter-1/vulkan_init_code/), this tutorial uses a bootstrap library to intialize Vulkan(https://github.com/charles-lunarg/vk-bootstrap/).
However when I use the library
in the VKBootstrapDispatch.h file, on line 2318 clang/cmake are complaining about VkPipelineInfoEXT not being a valid type. It suggests VkPipelineInfoKHR however when I switch the type, my code says that there are undefined symbols for arm64 and all of these functions relate to the library.
I couldn't find anything about this online, so it would be great if you could help. I'll attach some screenshots.
The errors are:
VkPipelineInfoEXT does not exist
VkPipelineInfoKHR works but then it says vulkan functions are undefined symbols.
This is what is says when I use KHR instead of EXT
_vkDestroyDevice", referenced from:
VulkanEngine::Cleanup() in VkEngine.cpp.o
"_vkDestroyImageView", referenced from:
VulkanEngine::Cleanup() in VkEngine.cpp.o
"_vkDestroyInstance", referenced from:
VulkanEngine::Cleanup() in VkEngine.cpp.o
"_vkDestroySurfaceKHR", referenced from:
VulkanEngine::Cleanup() in VkEngine.cpp.o
"_vkDestroySwapchainKHR", referenced from:
VulkanEngine::Cleanup() in VkEngine.cpp.o
ld: symbol(s) not found for architecture arm64
CMakeLists.txt
cmake_minimum_required(VERSION 3.13)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY) CMAKE_SOURCE_DIR}/build/debu
set(CMAKE_BUILD_TYPE Debug)
set(CMAKE_CXX_FLAGS "-std=c++17 -O3")
project(Vulkan-Raytracing-Project)
add_executable(Vulkan-Raytracing
${CMAKE_SOURCE_DIR}/src/main.cpp
${CMAKE_SOURCE_DIR}/src/VkEngine.cpp
${CMAKE_SOURCE_DIR}/lib/vkbootstrap/VkBootstrap.cpp
)
find_package(SDL2 REQUIRED)
find_package(Vulkan REQUIRED)
message(STATUS "Found SDL2")
message(STATUS "Found Vulkan")
# target_link_libraries(Vulkan-Raytracing PUBLIC SDL2 ${CMAKE_DL_LIBS})
target_link_libraries(Vulkan-Raytracing ${SDL2_LIBRARIES} $ {VULKAN_LIBRARIES})
# target_link_directories(Vulkan-Raytracing PUBLIC "${CMAKE_SOURCE_DIR}/lib/SDL")
# target_link_libraries(Vulkan-Raytracing PUBLIC libSDL2maind.a)
# target_link_libraries(Vulkan-Raytracing ${CMAKE_SOURCE_DIR}/lib/SDL/libSDL2maind.a)
target_include_directories(Vulkan-Raytracing PRIVATE
${SDL2_INCLUDE_DIRS}
${VULKAN_INCLUDE_DIRS}
"${CMAKE_SOURCE_DIR}/include"
"${CMAKE_SOURCE_DIR}/src"
"/Users/nick/VulkanSDK/1.3.211.0/macOS/include"
)
Sorry for answering my own question, but it turns out that Vulkan was not getting linked properly, and I included the .dylib that came with the sdk and the build worked.

Apple Mach-O Linker error with Allegro5 and Xcode with CMake

I'm trying to set up a project project in Xcode with allegro. I installed allegro5 using homebrew. My CMakeLists.txt is as below:
set(SOURCE_FILES "main.cpp")
add_executable(core ${SOURCE_FILES})
if(WIN32)
# TODO.
else(APPLE)
set(ALLEGRO_INCLUDE "/usr/local/include")
set(ALLEGRO_LIB "/usr/local/lib")
set(ALLEGRO_DYLIB, "/usr/local/lib/*.dylib")
set(ALLEGRO_LINK_FLAGS "-lallegro -lallegro_main")
endif()
include_directories(${ALLEGRO_INCLUDE})
link_directories(${ALLEGRO_LIB})
file(GLOB LIBRARIES ${ALLEGRO_DYLIB})
target_link_libraries(core ${LIBRARIES} ${ALLEGRO_LINK_FLAGS})
However, I keep getting the error: ld: library not found for -lallegro
EDIT:
Edited CMakeLists.txt file:
set(SOURCE_FILES "main.cpp")
add_executable(core ${SOURCE_FILES})
if(WIN32)
# TODO.
else(APPLE)
set(ALLEGRO_INCLUDE "/usr/local/include")
set(ALLEGRO_LIB "/usr/local/lib")
set(ALLEGRO_DYLIB, "/usr/local/lib/*.dylib")
endif()
include_directories(${ALLEGRO_INCLUDE})
link_directories(${ALLEGRO_LIB})
file(GLOB LIBRARIES ${ALLEGRO_DYLIB})
target_link_libraries(core ${LIBRARIES} ${ALLEGRO_DYLIB})
And now I'm getting the error:
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
(maybe you meant: __al_mangled_main)
ld: symbol(s) not found for architecture x86_64
You misunderstood target_link_libraries, you don't set the link flags here, but you indicate the list of libraries you want to target, so that would be:
target_link_libraries(core ${LIBRARIES} ${ALLEGRO_DYLIB})
Otherwise you will get flags like -l-lallegro.

Can't link libraries for C++11 on MacOS Mojave

I'm having trouble getting boost/openssl to link to my C++ project in CLion. I'm trying to build my program in CLion by clicking build, although I've also been trying to just manually compile with g++ but to no avail. My CMakeLists.txt looks like:
cmake_minimum_required(VERSION 3.12)
project(FinalProject)
set(CMAKE_CXX_STANDARD 11)
# Set OpenSSL dir, this should be default on linux/mac
set(OPENSSL_INCLUDE_DIR, /usr/local/opt/openssl/bin/openssl)
# Get OpenSSL
find_package(openssl REQUIRED)
# Get cppRestSDK
find_package(cpprestsdk REQUIRED)
find_package(boost REQUIRED)
# Compile + Link
add_executable(FinalProject main.cpp)
target_link_libraries(FinalProject cpprestsdk::cpprest)
I've tried changing
target_link_libraries(FinalProject cpprestsdk::cpprest)
to
target_link_libraries(FinalProject boost ssl cpprestsdk::cpprest)
and many other variations to ensure that all the dependencies I'm using get loaded (OpenSSL, cpprestsdk, and Boost) however I can't seem to get any of these to work as I keep getting various errors like:
"library not found for "-lssl", "-lboost", "-lopenssl"
I installed openssl using homebrew but when I run homebrew link openssl I get: "Refusing to link macOS-provided software: openssl" and adding --force gives me the same error message.
I've created symbolic links in the paths mentioned here but to no avail.
Running the CMakeLists.txt with just the target_link_libraries(FinalProject cpprestsdk::cpprest) gives me:
Undefined symbols for architecture x86_64:
"boost::system::detail::system_category_ncx()", referenced from:
boost::system::system_category() in main.cpp.o
"boost::system::detail::generic_category_ncx()", referenced from:
boost::system::generic_category() in main.cpp.o
ld: symbol(s) not found for architecture x86_64
But I can't figure out why since it seems Boost is loading fine (I get the message "Boost Version 1.68" when I build with target_link_libraries(FinalProject PRIVATE cpprestsdk::cpprest boost) but I also get the error ld: library not found for -lboost).
In my main.cpp (only file with code) I'm including:
#include <iostream>
#include <string>
#include <cpprest/http_client.h>
#include <cpprest/filestream.h>
#include "openssl/bio.h"
#include "openssl/ssl.h"
#include "openssl/err.h"
Anyone know what I'm missing? I'm guessing it's something simple in my CMakeLists.txt, but not sure. My only OpenSSL version is 1.0.2q and I'm on MacOS Mojave. Running openssl in my terminal does work, so it appears to be in my PATH. Really at a loss here as I'm not sure what's wrong at this point. Any help appreciated!
Specify that you want from boost. Here, you need "system":
find_package(Boost REQUIRED system)
Boost sets up variables to help after:
target_link_libraries(FinalProject ssl cpprestsdk::cpprest ${Boost_SYSTEM_LIBRARY})

CMake & dyld: Library not loaded: #rpath/libLTO.dylib

I am compiling my project using LLVM on Mac OS X with CLion and CMake.
My CMake configure is:
cmake_minimum_required(VERSION 3.6)
project(PPAP)
set(CMAKE_CXX_STANDARD 11)
# add_compile_options(-v)
include_directories(
/usr/local/Cellar/python3/3.6.0_1/Frameworks/Python.framework/Versions/3.6/include/python3.6m
/usr/local/Cellar/llvm/3.9.1/include
)
set(SOURCE_FILES src/parser.cpp src/convert.cpp src/ast.cpp)
set(LIBRARIES
/usr/local/Cellar/python3/3.6.0_1/Frameworks/Python.framework/Versions/3.6/lib/libpython3.6.dylib
/usr/local/Cellar/llvm/3.9.1/lib/libLLVM.dylib
)
add_executable(PPAP ${SOURCE_FILES})
target_link_libraries(PPAP ${LIBRARIES})
Then I compile it successfully, but when I run it, I got:
dyld: Library not loaded: #rpath/libLTO.dylib
Referenced from: /usr/local/opt/llvm/lib/libLLVM.dylib
Reason: image not found
How to solve this problem?
Just linking libLLVM.dylib is not enough. Using llvm-config instead of adding libraries manually is a better way.
It's not ideal, but adding the library directories to the DYLD_LIBRARY_PATH environment variable in the CLion Run/Debug Configurations made the errors go away for me.
I'm still interested in a CMake-only solution without having to resort to DYLD_LIBRARY_PATH.

Linking to a static library that uses boost libraries causes link errors in cmake

I am developing a library (let's say mylibrary) to be used by some third-party applications. My library is build and compiled by cmake (on CentOS 7 and g++ 4.8) and uses some boost libraries, such as thread, log, system, filesystem and date_time (version 1.61.0). To test my lib, I've developed a very simple tester (let's call it tester). The point is that my library can by successfully built and linked, but the tester cannot. Let me show the contents of cmake files below:
In the main cmake file that is dedicated to building mylibrary, I have added boost in this way:
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
SET(Boost_ADDITIONAL_VERSIONS "1.51.0" "1.52.0"
"1.53.0" "1.54.0" "1.55.0" "1.56.0" "1.57.0" "1.58.0"
"1.60.0" "1.61.0" "1.61.0" "1.62.0" "1.63.0" "1.64.0")
find_package(Threads)
find_package(Boost REQUIRED)
find_package(Boost 1.61.0 COMPONENTS thread log log_setup filesystem system date_time)
include_directories(${Boost_INCLUDE_DIRS})
link_directories(${Boost_LIBRARY_DIRS})
To add the library, I have used these lines of code:
set(MYLIBRARY_SRC
${MYLIBRARY_SOURCE_DIR}/src/folder1/File1.cpp
${MYLIBRARY_SOURCE_DIR}/src/folder2/File2.cpp
${MYLIBRARY_SOURCE_DIR}/src/folder3/File3.cpp)
add_library (mylibrary ${MYLIBRARY_SRC})
In the last lines of this cmake files, I have added the tester directory in this way:
if(ENABLE_TESTER)
message(STATUS "tester is enabled and will be built")
add_subdirectory (tester)
endif(ENABLE_TESTER)
and for the tester, I have a very simple cmake file like this:
add_executable(tester tester.cpp)
message(STATUS , "Boost_libraries are ${Boost_LIBRARIES}")
target_link_libraries(tester mylibrary ${Boost_LIBRARIES})
Now, whenever I build my project, my library is built successfully, but when the tester is going to be linked, I face lots of linker errors like this:
../../lib/mylibrary.a (Logger.cpp.o): In function `void boost::log::v2s_mt_posix::basic_formatting_ostream<char, std::char_traits<char>, std::allocator<char> >::aligned_write<wchar_t>(wchar_t const*, long)':
/home/john/local/include/boost/log/utility/formatting_ostream.hpp:702: undefined reference to `boost::log::v2s_mt_posix::aux::code_convert(wchar_t const*, unsigned long, std::string&, std::locale const&)'
/home/john/local/include/boost/log/utility/formatting_ostream.hpp:696: undefined reference to `boost::log::v2s_mt_posix::aux::code_convert(wchar_t const*, unsigned long, std::string&, std::locale const&)'
The point is that I have printed the Boost_LIBRARIES variable before linking the tester and everything seems fine.
Well, the root cause of this issue was exactly the same asked in this question.
p.s. J.J.Hakala answered this question in the comments. I asked him to write his reply as an answer, so I can accept it. But he has not replied yet and I decided to write the answer myself. If this action is wrong form S.O.'s point of view or if I should ask moderators to make my Q duplicate, please let me know.