Undefined symbol: _new_tunnel about boringtun HOT 1 OPEN

Investigation

Following up on my own issue, after a lot of digging and testing, I realized that the command line to build the library, which was provided in the README.md, is the issue. The command line specifies --no-default-features, which disables most of the code for the library. In fact, the Cargo.toml includes an empty Default feature definition anyway, so with or without the command line option, the resulting library would be unusable.

I believe the correct command line for building for an iPhone is:

cargo build --lib --release --features "device ffi-bindings" --target aarch64-apple-ios

Obviously, if you were building for a different platform which required the JNI bindings you would need to include that in the feature list as well.

Conclusion

This is a documentation bug and should be resolved to prevent this issue for others.

I admit that my knowledge of Cargo at the start of this was quite limited, so I was relying heavily on the README.md and the information available in the repository. Having dug a little deeper into the package manger, I realized that no features were enabled by default and in fact the resulting library contained virtually no Wireguard code. Why the code was shipped this way is a bit of a mystery to me.

It seems like adding a minimal set of features to the Default feature and removing the --no-default-features flag from the documentation would be a good solution here.

Other useful information

As a side note, it is probably also worth mentioning that the nm included with the XCode command line tools does not appear compatible with the object format produced by the Rust LLVM. That leads to a lot of errors and missing symbols when dumping the library contents. For example:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: 
libboringtun.a(boringtun.boringtun.d968bf83758f975a-cgu.0.rcgu.o): Unknown attribute kind (86) 
(Producer: 'LLVM17.0.6-rust-1.77.1-stable' Reader: 'LLVM APPLE_1_1500.3.9.4_0')

I found that Objdump was able to dump the library without issues.

objdump -d libboringtun.a

I also found the binutils, available from Homebrew, provided a usable nm. I was able to use gnm to successfully dump the contents of the library. This can be installed and used with the following commands.

brew install binutils
/usr/local/opt/binutils/bin/gnm libboringtun.a

from boringtun.