Failed to link bzip on macOS aarch64

[thewh1teagle]

I use bzip2 crate in sherpa-rs and users report that it failed to compile with the error:

process didn't exit successfully: `/Users/enes/Desktop/whisper_test/target/debug/build/sherpa-rs-sys-5009514fe91242ca/build-script-build` (signal: 6, SIGABRT: process abort signal)
  --- stderr
  dyld[7708]: Library not loaded: @rpath/libbz2.1.dylib

On some machines it works on aarch64, for instance for me. but for others it doesn't. Maybe related to macOS version.
Is there a workaround?
I see that you use static version of bzip so I guess it also compile it. any idea why it failed to link it?

Thanks

Related:
thewh1teagle/sherpa-rs#25
tauri-apps/tauri#10983

Btw. the issue fixed when enabled static feature. due is still be useful to use it dynamically.

[jbg]

tauri-apps/tauri#10983 (comment) might be helpful.

The core issue seems to be that the bzip2-sys build script finds a bzip2 library via pkg-config but that library is not on the dyld search path at runtime.

In my case it was a custom PKG_CONFIG_PATH environment variable, but linking the homebrew bzip2 package (against the advice in the package info) could probably also cause it, or anything else involving a non-system bzip2 library.

[folkertdev]

We recommend that you use the rust implementation with the libbz2-rs-sys feature. It is more performant, and because of dead code elimination the impact on binary size should be minimal.

https://github.com/trifectatechfoundation/bzip2-rs?tab=readme-ov-file#features

We will make that implementation the default soon.

[jbg]

Most people facing these issues are probably using some crate where bzip2 is a transitive dependency (in my case about six crates deep), so unless features to control bzip2 build options are propagated all the way through from the crate they are actually trying to install, this isn't currently an option for them. Making it the default will certainly work though!

[bjorn3]

If you add add a direct dependency on bzip2, you can enable the feature for this dependency and then feature unification will cause it to apply to the indirect dependency on bzip2 too.

[jbg]

Yup, that works well for some cases, but in both cases that I hit this (dioxus and trunk) I was trying to cargo install something, so I'd have to fork the package I was installing to add the dep. A lot of the other mentions of this issue online seem to be in the same boat.

In general using Cargo features for things that the "end-user" (as opposed to the author of the crate directly depending on bzip2) wants to control seems less-than-perfect. An environment variable would allow easier control by the end-user, but suffers from a lack of discoverability and lack of standardization. (I realize this is an issue across the whole cargo ecosystem and not specific to this package.)

[NobodyXu]

(I realize this is an issue across the whole cargo ecosystem and not specific to this package.)

Maybe it would makes more sense for cargo allow enabling features of transitive dependencies via environment variables?

That would make building binaries much easier