Unable to build shared library with FetchContent

[WillAyd]

Not sure if this is an issue with the library or just a CMake thing, but I am unable to get anything but a static library when using FetchContent to pull in the nanoarrow dependency. My CMakeLists.txt looks like:

cmake_minimum_required(VERSION 3.18)
project(${SKBUILD_PROJECT_NAME} LANGUAGES C CXX)
set(CMAKE_C_STANDARD 17)
set(CMAKE_C_STANDARD_REQUIRED ON)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

if (MSVC)
else()
    add_compile_options(-Wall -Wextra)
endif()

find_package(Python COMPONENTS Interpreter Development.Module REQUIRED)

# Detect the installed nanobind package and import it into CMake
execute_process(
  COMMAND "${Python_EXECUTABLE}" -m nanobind --cmake_dir
  OUTPUT_STRIP_TRAILING_WHITESPACE OUTPUT_VARIABLE NB_DIR)
list(APPEND CMAKE_PREFIX_PATH "${NB_DIR}")
find_package(nanobind CONFIG REQUIRED)

include(FetchContent)
FetchContent_Declare(nanoarrow-project
  GIT_REPOSITORY https://github.com/apache/arrow-nanoarrow.git
  GIT_TAG apache-arrow-nanoarrow-0.3.0
)
FetchContent_MakeAvailable(nanoarrow-project)

nanobind_add_module(somelib somelib.cpp)
target_link_libraries(somelib PRIVATE nanoarrow)
install(TARGETS somelib
  LIBRARY DESTINATION ${SKBUILD_PROJECT_NAME})

You can see the full project here

I've had tried cmake -S . -B build -DBUILD_SHARED_LIBS=ON and scattering SET(BUILD_SHARED_LIBS ON) throughout the CMakeLists.txt, but regardless of what I do I always end up with a static libnananoarrow. Is that expected?

[paleolimbot]

I definitely would have expected that either of those options would result in a shared nanoarrow; however, I'm not an expert in CMake and it's come up recently that our CMake config is not all that helpful for some other patterns as well (#352).

I'm also not an expert in skbuild/Python builds in general...I expected most people to just include nanoarrow.c in the sources for add_library(), but it looks like nanobind has its own thing for that and maybe you can't just add another .c source file there.

I think you might also want to set NANOARROW_NAMESPACE as well (to make sure that your package's nanoarrow doesn't collide with another version of nanoarrow in another package). We definitely need to do a better job documenting/testing the various configuration in which we expect nanoarrow to be actually used 🙂 .

[WillAyd]

Specifically for Python packaging I have been able to work around this in the meantime while living with the static library and just setting fPIC on that.

set_target_properties(nanoarrow
                      PROPERTIES POSITION_INDEPENDENT_CODE
                      ON)

[paleolimbot]

I've also run into the need to set -fPIC when linking nanoarrow, so maybe that needs to be a CMake option as well (in addition to figuring out/testing more CMake setups).

[vyasr]

This no longer appears to be an issue. When I clone the linked repo and run

cmake -S . -B build -DBUILD_SHARED_LIBS=ON && cmake --build build

I see

[ 27%] Linking C shared library libnanoarrow.so

and

(rapids) coder _ ~/local/testing/nanoarrow/issue_364 $ ls build/_deps/nanoarrow-project-build/
CMakeFiles  Makefile  cmake_install.cmake  generated  libnanoarrow.so

Perhaps something has been fixed in nanoarrow's CMake since then?

[WillAyd]

Hmm strangely I still get the static library

[WillAyd]

Actually ignore previous comment - yes I do see nanoarrow as shared now