I am using Windos 10, Clang 11.0 installed from Visual Studio installer. I want to use library redis++, so I first installed library hiredis (I built it with selecting toolset "cmake -T ClangCL ...") and then installed redis++ with similar cmake command.
My CMakeLists.txt file for simple test project looks like this:
cmake_minimum_required(VERSION 3.18)
project(HELLO)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
add_executable(target hello.cpp)
find_package(hiredis)
target_include_directories(target PUBLIC ${HIREDIS_HEADER})
target_link_libraries(target ${HIREDIS_LIB})
find_package(redis++)
target_include_directories(target PUBLIC ${REDIS_PLUS_PLUS_HEADER})
target_link_libraries(target ${REDIS_PLUS_PLUS_LIB})
hello.cpp looks like:
#include <sw/redis++/redis++.h>
using namespace sw::redis;
in main(int argc, char *argv[]){
auto redis = Redis("tcp://127:0:0:1:6379");
const sw::redis::StringView key = "test";
redis.rpop(key);
return 0;
}
When I build the project, I get error lld-link error: undefined symbol sw::redis::Redis::rpop
. If I just call redis.pop()
(without passing argument), I get too few arguments to function call
.
So I am not really sure what is going on, if I call rpop() in invalid way, it sees the function signature and tells me I need to pass an argument, but when I pass it, it says linking error.
Successful call to
find_package(redis++)
creates IMPORTED targets redis++::redis++
for the shared library and redis++::redis++_static
for the static library. For use Redis++ you need to link one of these targets into the executable:
target_link_libraries(target redis++::redis++)
(Linkage with the IMPORTED target automatically sets include directories, so the call to target_include_directories
is not needed.)
The approach with using variables REDIS_PLUS_PLUS_HEADER
and REDIS_PLUS_PLUS_LIB
works if you set these variables in corresponding find_path
and find_library
calls, as described in their docs: https://github.com/sewenew/redis-plus-plus#build-with-cmake.
As with any other project, find_package
approach (described at the beginning of that post) is always a preferred way.