Fix nanobind on MacOS

[oscargus]

I get the following problem with the latest nanobind wrap:

        ld: file cannot be open()ed, errno=2 path=x in 'x'

both in the CI and when building locally.

Now, I am far from a linker expert, but as far as I can tell, the x comes from

wrapdb/subprojects/packagefiles/nanobind/meson.build

Line 55 in c068c10

dep_link_args += ['-Wl,-dead_strip', '-Wl,x', '-Wl,-S', '-Wl,@' + resp_file]

but I would guess that the idea is that it should be -Wl,-x

-x, --discard-all
Delete all local symbols.

Strange thing is that this x has been around since the initial version of the wrap, but I have never triggered it before. However, I also note the build process is a bit different for my project, with just a single nanobind-files being compiled

       [31/33] Compiling C++ object _apytypes.cpython-310-darwin.so.p/subprojects_nanobind-2.7.0_src_nb_combined.cpp.o

instead of about ten earlier. So this is nice, but also seems to trigger this issue.

CC: @hpkfft - you didn't change the linker flag, but maybe know more about what could have changed and why I now trigger that path (which, again, is an improvement, except for the bug)
@WillAyd - you created the first version. Is the -Wl,x instead of -Wl,-x a typo or am I missing something?

Btw, is there a good way to test a new wrap locally?

[WillAyd]

Cool thanks for the PR

@WillAyd - you created the first version. Is the -Wl,x instead of -Wl,-x a typo or am I missing something?

Probably just an oversight. It looks like the CMake configuration adds the hypen as you suggest:

https://github.com/wjakob/nanobind/blob/62fc996018d9ea4d51af9c86cf008c2562b4eeab/cmake/nanobind-config.cmake#L315

Btw, is there a good way to test a new wrap locally?

Make sure you have updated your tags from the upstream repo:

git fetch upstream --tags

then you can run ./tools/sanity_checks.py

[oscargus]

Thanks for a quick reply. Then it seems to maybe be the reason.

I was primarily thinking about building my program with the new wrapdb without it being merged. But a sanity check is of course always good to do as well!

[WillAyd]

Someone else likely has a more robust way of doing it, but you can try editing the files in your projects subprojects/nanobind/ directory directly

[oscargus]

Thanks!

I can at least then confirm that adding - fixed that error.

(And now I have some totally unrelated errors that I only saw on CI, but not locally earlier, so probably a hint for those as well as a bonus. But not at all related to nanobind, so I think this is good to go.)

[hpkfft]

@hpkfft - you didn't change the linker flag, but maybe know more about what could have changed and why I now trigger that path (which, again, is an improvement, except for the bug)

Previously, the linker args for stripping were only applied if get_option('buildtype') == 'shared'. However, they should be applied to the user's extension, not only to the shared library libnanobind.so, which actually is not built by the nanobind subproject (using meson).
Sorry, I was only able to test on Linux, so I did not discover the typo in the macos dep_link_args.

As a further thought, one might consider making stripping conditional on if get_option('buildtype') == 'release'....

[hpkfft]

Line 60: if get_option('buildtype') == 'shared'
This test is wrong. The variable buildtype is for debug or release, etc.

What is wanted here is probably default_library.

The goal of this code is to allow the main project to get the flags it needs to build libnanobind.so, if that is desired.
It's an advanced use case, say for an extension that builds ten or more python modules and so wants to build libnanobind.so rather than statically linking that functionality into all ten python modules.

[oscargus]

Thanks! Did I understand correctly that line 60 should look like in the second commit? (At least it may not be more incorrect than the current...)

[hpkfft]

Yes. Thank you, Oscar.

[oscargus]

@jpakkane as you merged the latest version, would you mind taking a look at this?