search

nicholasjng / nanobind-bazel

Bazel defs and rules for building Python projects with nanobind extensions.
Apache License 2.0
6 stars 0 forks source link

Investigate how to bundle both static and shared `libnanobind` in `@nanobind` dep #9

Closed nicholasjng closed 3 months ago

nicholasjng commented 3 months ago

In #7, converting the @nanobind//:nanobind target into a shared libnanobind[.so] by using the NB_SHARED macro didn't work, causing inconsistent DLL linkage warnings (MSVC C4273) and subsequent build errors.

My understanding is that this happens because the addition of the libnanobind-static target results in both @nanobind//:nanobind and @nanobind//:libnanobind making it into the build deps, and then MSVC's linker cannot decide between the symbols from either one or the other.

It would be best to dynamically select between either of these two deps depending on what is needed, on all platforms. The decision could possibly be made as easily as by the linkstatic attribute of the nanobind_library or the fully_static_link feature of the cc_binary features.

nicholasjng commented 3 months ago

Link to a failed CI job, e.g. for Python 3.8 -> https://github.com/nicholasjng/nanobind-bazel/actions/runs/8216397874/job/22470929403.

nicholasjng commented 3 months ago

On that note, I am suspicious of the large amount of duplication that I'm currently doing for options of libnanobind-static, where the only variety is really the different Linux linker options.

Maybe it's possible by giving specific args to the nanobind_extension to force static linking (e.g. features = ["fully_static_link"] by the looks of it from the docs) and build a libnanobind.a only if that feature (or linkstatic = True) is given.

nicholasjng commented 3 months ago

Closed by #7, the @nanobind//:nanobind target now becomes a shared or static library depending on what the user requests.