Open RandomExplosion opened 3 years ago
And what happens when you follow the instructions in the error and set LIBCLANG_PATH? Does that not resolve it?
i just went and installed a new version of libclang and now i get
error: failed to run custom build command for `speech-dispatcher-sys v0.5.2`
Caused by:
process didn't exit successfully: `/share/lightbox_rs/target/debug/build/speech-dispatcher-sys-92155df6d9f2566e/build-script-build` (exit code: 101)
--- stdout
cargo:rustc-link-lib=speechd
--- stderr
wrapper.h:1:10: fatal error: 'speech-dispatcher/libspeechd.h' file not found
wrapper.h:1:10: fatal error: 'speech-dispatcher/libspeechd.h' file not found, err: true
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ()', /home/benjamin.mcgaw/.cargo/registry/src/github.com-1ecc6299db9ec823/speech-dispatcher-sys-0.5.2/build.rs:9:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
it also appears to be the same error being hit by docs.rs https://docs.rs/crate/tts/0.12.2
I just tried running sudo apt-get install -y libspeechd-dev as that is what you do in your unit tests and I now get this:
error[E0308]: mismatched types
--> /home/benjamin.mcgaw/.cargo/registry/src/github.com-1ecc6299db9ec823/speech-dispatcher-0.7.0/src/lib.rs:131:37
|
131 | let index_mark = CStr::from_ptr(index_mark);
| ^^^^^^^^^^ expected `u8`, found `i8`
|
= note: expected raw pointer `*const u8`
found raw pointer `*mut i8`
error[E0308]: mismatched types
--> /home/benjamin.mcgaw/.cargo/registry/src/github.com-1ecc6299db9ec823/speech-dispatcher-0.7.0/src/lib.rs:208:33
|
208 | (*c).callback_im = Some(cb_im);
| ^^^^^ expected `u8`, found `i8`
|
= note: expected fn pointer `unsafe extern "C" fn(_, _, _, *mut u8)`
found fn item `unsafe extern "C" fn(_, _, _, *mut i8) {cb_im}`
error[E0308]: mismatched types
--> /home/benjamin.mcgaw/.cargo/registry/src/github.com-1ecc6299db9ec823/speech-dispatcher-0.7.0/src/lib.rs:329:61
|
329 | let v = unsafe { spd_wchar(self.0, priority as u32, wchar) };
| ^^^^^ expected `u32`, found `i32`
|
help: you can convert an `i32` to `u32` and panic if the converted value wouldn't fit
|
329 | let v = unsafe { spd_wchar(self.0, priority as u32, wchar.try_into().unwrap()) };
| ^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to 3 previous errors
For more information about this error, try `rustc --explain E0308`.
error: could not compile `speech-dispatcher`.
I don't have access to an arm box to test on, and I can't seem to duplicate this in either WSL or in GitHub's x86 CI. If you could debug this and send a PR, that'd be helpful.
Thanks!
I'm a bit confused as a lot of the errors seem to be type errors related to the intergers i'll try modifying the source and seeing if that helps
You probably want to look at https://github.com/ndarilek/speech-dispatcher-rs.
I just casually tried swapping the types to u8
and the build failed.
Looks like bindgen may be generating slightly different code on ARM.
If you can tweak enough types to get speech-dispatcher-rs building on ARM and submit a PR, I'll add the necessary conditional compilation magic to make it work on X86 and push out a new release. It shouldn't be too challenging--just tweak the types in the failing function signatures until it builds. I can't do it because I don't have an ARM system, sorry.
Just wanted to mention I'm getting a similar error on a MacBook Air M1 (that is, ARM):
error[E0308]: mismatched types
--> /Users/oskarthornblad/.cargo/registry/src/github.com-1ecc6299db9ec823/tts-0.14.0/src/backends/appkit.rs:201:27
|
201 | Ok(is_speaking == YES)
| ^^^ expected `i8`, found `bool`
These should all be fairly easy fixes--just cast the variables correctly and add a feature check that matches the ARM version of whatever platform you're on--but I'm unlikely to have anything myself anytime soon so it'll have to come from someone else. Sorry.
The compilation error has been fixed on the M1, but I can't get speech working on this platform. I also vaguely recall that I didn't get speech working on iOS either, but at the time I didn't debug further since I had other things to work on.
Hoping the Linux issues should be easily fixed, since the compiler is catching them. I'm more worried about macOS, though, since the only way to call these APIs is to unsafely poke a bunch of ObjC at runtime and the compiler can't help. If anyone has any deeper mac experience, that'd be greatly appreciated.
In the meantime, I'll see if I can at least score an Arm Linux server and get things compiling there. I'm curious if this is a general Arm failure, or if it just doesn't work on macOS.
I have zero experience, but just wanted to let you know that I successfully get speech on my M1 using this: https://github.com/ndarilek/tts-rs/pull/7
@prewk meet @ghorthalon. You're both trying to get this working on M1s, except it works for you and doesn't for him. It also works for me on my Intel mac.
I am genuinely at a loss as to what to try next, other than posting to the Rust forums and hoping some mac Rust expert helps out. Would you two mind connecting sometime and seeing what you can figure out?
You'll want to use master, since I added more logging and fixed the M1 compilation issue. RUST_LOG=trace cargo run --example hello_world
should give you a bunch of logging.
I'd be very interested in any differences between your systems that might account for this behavior. Are you using different default languages, different default voices, or something else?
Thanks a bunch.
I basically just did
let mut tts = TTS::new(Backends::AppKit).unwrap();
speaker.tts.speak("foo".to_string(), true).unwrap();
so everything default, I guess. (with https://github.com/ndarilek/tts-rs/pull/7)
Oh, so you're explicitly using the AppKit backend? Never mind, then. I thought you were using the default. Sorry for the ping, Talon.
Ahh, no my bad I might've just misunderstood how to use it properly haha.
I'd be curious if swapping that out for a call to TTS::default()?
breaks things for you too. That should pick a sensible default for
whatever platform you're on, which in your case will be AVFoundation.
It's breaking for other folks, but learning that it breaks for you too
would at least give me a bit more closure. :)
Tried it - compiled but no sound!
OK, good, we're back to everyone having the same problem. Whew. :P
Haha that's good (and bad!).
Coming to this late, would suggest that usually when considering a conditional cast to i8
the correct answer is instead to unconditionally use c_char
(or whatever it's called, I'm on mobile and holding a baby).
Expected Behaviour: Project builds and runs successfully after adding tts to the dependencies list
Actual Behaviour: Project fails to run despite not using the library anywhere in code
running with a backtrace yields the following: