Building NB_MODULE with enum dependency

[mthramann]

Apologies if I've missed this in the documentation, but should nanobind support building a module using other linked libraries?

Example:

# CMakeLists.txt
cmake_minimum_required(VERSION 3.15...3.27)
project(test_nanobind)

# This is necessary for linking mylib
set(CMAKE_POSITION_INDEPENDENT_CODE ON)

find_package(Python 3.8 COMPONENTS Interpreter Development.Module REQUIRED)

if (NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
  set(CMAKE_BUILD_TYPE Release CACHE STRING "Choose the type of build." FORCE)
  set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "MinSizeRel" "RelWithDebInfo")
endif()

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)

# We build nanobind and privately link to mylib instead of using nanobind_add_module,
# because MODULE libraries can't be linked into other targets
# https://cmake.org/cmake/help/latest/command/add_library.html#normal-libraries
nanobind_build_library(nanobind)

add_library(mylib mylib.cpp)
target_link_libraries(mylib PRIVATE nanobind)

nanobind_add_module(test_nanobind test_nanobind.cpp)
target_link_libraries(test_nanobind PRIVATE mylib)

// test_nanobind.cpp
#include <nanobind/nanobind.h>

void bind_mylib(nanobind::module_& m);

NB_MODULE(test_nanobind, m) {
  bind_mylib(m);
}

// mylib.cpp
#include <nanobind/nanobind.h>

enum class MyEnum { Thing1, Thing2 };

// int add(int a, int b) { return a + b; }

void bind_mylib(nanobind::module_& m) {
  //  m.def("add", &add);
  nanobind::enum_<MyEnum>(m, "MyEnum")
    .value("Thing1", MyEnum::Thing1)
    .value("Thing2", MyEnum::Thing2);
}

This will build but import test_nanobind will segfault. When I remove the nanobind::enum_ and instead uncomment the mult definition and binding, I can import and call mult (similar to the nanobind example).

Is nanobind intended to support this use case? And if not, what is the recommended workaround?

I'm using version 1.8.0.

Thank you.

[wjakob]

This is a bit of an unusual setup. The traditional way would be to have your library (mylib) contain project code which is not related to the Python bindings. The python bindings import this library and expose the contained functionality.

The problem in your case is that you are linking libnanobind twice. Once as a shared library, and once as a static one. The shared version linked by these lines

nanobind_build_library(nanobind)
target_link_libraries(mylib PRIVATE nanobind)

is never properly initialized, and a lookup for internal data structures eventually crashes when a pointer is NULL. The easy fix is to add NB_SHARED to the nanobind_add_module call. Then both use the same library, and the bindings do the initialization.

[mthramann]

Once as a shared library, and once as a static one.

Ah, thank you. I didn't pick up this difference in the docs:
nanobind_add_module: Option NB_STATIC: (this is the default)
nanobind_build_library: Option -static: without this suffix, a shared build is used