Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`
Sebastian Ramacher, le lun. 15 avril 2024 05:41:48 +0200, a ecrit: > On 2024-04-14 14:19:18 +0200, Santiago Vila wrote: > > El 14/4/24 a las 13:25, Sylvestre Ledru escribió: > > > I am sorry but I am not sure to see how it is actionable. > > > > > > Without a test case, i don't think there is much I can do here. > > > > The test case is that nvda2speechd fails to build from source. > > > With rust, cargo, custom build script, there are many things that can go > > > wrong before LLVM. > > > > > > Sebastian, I think it could be move to normal. From LLVM perspective, it > > > isn't serious severity (many programs are built with LLVM 16). > > > > We can release trixie with compilers having bugs, but I don't think it > > would be ok at > > all to release trixie as stable with packages which do not build from > > source, that would > > be against Release Policy. > > > > So, in my opinion, this is still RC, either in the compiler or in the > > package failing > > to build. If solving this in the compiler is too complex, then the bug > > should be reassigned back to src:nvda2speechd. > > Given that nvda2speechd downloads rust and plenty of crates during the > build, it will have to prevent odd interactions with the system provided > LLVM. Let's keep this as RC bug against nvda2speechd. The problem is that bindgen insists on interacting with the system-provided LLVM: https://github.com/rust-lang/rust-bindgen/blob/main/bindgen/lib.rs#L620 It force-loads libclang, and when that's libclang16, we get the bug. For now I "fixed" the bug by dropping the rust/cargo/clang build-deps entirely, and build-dep on libclang 14 rather than 16. I don't know why the issue shows up only when building speech-dispatcher-sys, perhaps that's just because it's the only crate that uses bindgen. Samuel
Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`
On 2024-04-14 14:19:18 +0200, Santiago Vila wrote: > El 14/4/24 a las 13:25, Sylvestre Ledru escribió: > > I am sorry but I am not sure to see how it is actionable. > > > > Without a test case, i don't think there is much I can do here. > > The test case is that nvda2speechd fails to build from source. > > With rust, cargo, custom build script, there are many things that can go > > wrong before LLVM. > > > > Sebastian, I think it could be move to normal. From LLVM perspective, it > > isn't serious severity (many programs are built with LLVM 16). > > We can release trixie with compilers having bugs, but I don't think it would > be ok at > all to release trixie as stable with packages which do not build from source, > that would > be against Release Policy. > > So, in my opinion, this is still RC, either in the compiler or in the package > failing > to build. If solving this in the compiler is too complex, then the bug should > be reassigned back to src:nvda2speechd. Given that nvda2speechd downloads rust and plenty of crates during the build, it will have to prevent odd interactions with the system provided LLVM. Let's keep this as RC bug against nvda2speechd. Cheers -- Sebastian Ramacher
Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`
El 14/4/24 a las 13:25, Sylvestre Ledru escribió: I am sorry but I am not sure to see how it is actionable. Without a test case, i don't think there is much I can do here. The test case is that nvda2speechd fails to build from source. With rust, cargo, custom build script, there are many things that can go wrong before LLVM. Sebastian, I think it could be move to normal. From LLVM perspective, it isn't serious severity (many programs are built with LLVM 16). We can release trixie with compilers having bugs, but I don't think it would be ok at all to release trixie as stable with packages which do not build from source, that would be against Release Policy. So, in my opinion, this is still RC, either in the compiler or in the package failing to build. If solving this in the compiler is too complex, then the bug should be reassigned back to src:nvda2speechd. Thanks.
Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`
Hello I am sorry but I am not sure to see how it is actionable. Without a test case, i don't think there is much I can do here. With rust, cargo, custom build script, there are many things that can go wrong before LLVM. Sebastian, I think it could be move to normal. From LLVM perspective, it isn't serious severity (many programs are built with LLVM 16). Cheers Sylvestre Le 06/12/2023 à 02:13, Samuel Thibault a écrit : Control: reassign -1 libclang1-16 Sorry, I meant to reassign to libclang1-16 of course.
Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`
Control: reassign -1 libclang1-16 Sorry, I meant to reassign to libclang1-16 of course.
Bug#1057586: nvda2speechd: FTBFS: error: failed to run custom build command for `speech-dispatcher-sys v0.7.0`
Control: reassign -1 clang-15 Control: affects -1 src:nvda2speechd Hello, Santiago Vila, le mar. 05 déc. 2023 23:08:27 +0100, a ecrit: > During a rebuild of all packages in unstable, your package failed to build: > [...] > Running > `/<>/src/server/target/release/build/speech-dispatcher-sys-0141496207297e1b/build-script-build` > error: failed to run custom build command for `speech-dispatcher-sys v0.7.0` > > Caused by: > process didn't exit successfully: > `/<>/src/server/target/release/build/speech-dispatcher-sys-0141496207297e1b/build-script-build` > (exit status: 101) > --- stdout > cargo:rustc-link-lib=speechd > > --- stderr > thread 'main' panicked at > '"__mbstate_t_union_(unnamed_at_/usr/include/x86_64-linux-gnu/bits/types/__mbstate_t_h_16_3)" > is not a valid Ident', > /<>/tmp/registry/src/github.com-1ecc6299db9ec823/proc-macro2-1.0.39/src/fallback.rs:700:9 This doesn't happen in bookworm. I don't know where this "(unnamed_at_...)" part comes from exactly, possibly from ./llvm/lib/IR/Mangler.cpp:getNameWithPrefixImpl(OS, "__unnamed_" + Twine(ID), DL, PrefixTy); ./llvm/lib/Passes/StandardInstrumentations.cpp: out << "unnamed_" << FuncOrderBlockNum << "<" << BB << ">"; but what is sure is that when, starting from a bookworm chroot, I merely install libclang1-16 from trixie, I get the issue (installing libclang1-15 doesn't trigger it). Samuel
