Skip to content

Conversation

@nicholasjng
Copy link
Owner

@nicholasjng nicholasjng commented Nov 24, 2025

This way, libraries can consume symbols from dynamically linked libnanobinds, i.e. shared library builds of nanobind.

Closes #81. This hopefully also fixes LLVM build failures seen in llvm/llvm-project#169306, when released on the BCR.

Maybe someone with more experience can explain if these definitions impact static linkage of nanobind.

This way, libraries can consume symbols from dynamically linked libnanobinds,
i.e. shared library builds of nanobind.
@nicholasjng nicholasjng self-assigned this Nov 24, 2025
@wjakob
Copy link

wjakob commented Nov 24, 2025

NB_SHARED enables DLL linkage for exported libnanobind symbols. When doing a shared build, you must set NB_BUILD to export symbols, otherwise the default is that they are imported. This is especially important for windows where the symbol export/import direction must be specified for each symbol. When doing static builds NB_SHARED should not be specified. The NB_BUILD flag is ignored if NB_SHARED is not set.

@nicholasjng
Copy link
Owner Author

Thank you! That helps.

I'm not sure if I can control defines passed to a cc_library based on its linkage, or if a cc_library target can have multiple linkages, but both JAX/XLA and LLVM set these unconditionally, and they seem to be fine. I'll ask around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Building nanobind with NB_SHARED and NB_BUILD

3 participants