CMake cyclic dependency error when a custom library name is the same as a system library

Question

I'm writing a CMakeLists.txt file to build a C++ project of mine, which is composed of

1. libhybris.so: A shared library with some exported functions.
2. hybris: An executable which links to libhybris.so
3. A set of various shared libraries which links to libhybris.so

The problem is that, libhybris.so depends on libpcre (for regular expression capabilities), so I have the following statements:

# libhybris.so generation
add_library( libhybris 
             SHARED 
             ${LIB_SOURCES} )

...

# Needed libraries
target_link_libraries( libhybris 
                       dl 
                       pcre 
                       pthread
                       readline )

And one of the shared libraries from point 3, is called pcre.so, so I have the following too:

add_library( pcre SHARED ${PCRE_SOURCES} )

...

target_link_libraries( pcre
                       dl 
                       pcre 
                       curl
                       pthread
                       readline
                       ffi 
                       libhybris )

So, when I run a "cmake .", I have the following error:

-- Configuring done
CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
  "libhybris" of type SHARED_LIBRARY
    depends on "pcre"
  "pcre" of type SHARED_LIBRARY
    depends on "libhybris"
At least one of these targets is not a STATIC_LIBRARY.  Cyclic dependencies are allowed only among static libraries.

Because CMake thinks that the libhybris.so pcre dependency (system libpcre.so) is the same of my pcre.so which it is obviously not.

How can I solve this problem without changing the pcre.so name?

Twombly

Answer 1

In CMake, the recommended way is to specify any link libraries with the full path. To get the full path for the system library, you can either use FIND_PACKAGE(...) if supported or simply FIND_LIBRARY(...)

For example,

FIND_LIBRARY( PCRE_SYSTEM_LIB pcre )

ADD_LIBRARY( libhybris SHARED ${LIB_SOURCES} )
TARGET_LINK_LIBRARIES( libhybris
                       ${PCRE_SYSTEM_LIB}
                       ......
                      )

This will prevent CMake from expanding something it recognizes as a target (nameley pcre) to the full path of that target.

Puglia

Answer 2

It depends on your development environments. You can set a build path to overcome these difficulties.

Shir

If i don't set the name explicitly (giving the full path of libhybris.so for instance) cmake will not recognize libhybris.so as a dependency of pcre.so, i've already tried that. – Twombly