Arch Linux User Repository

To make the build pass the tokio error, I make explicit the usage of tokio_unstable. I don't know why thi has been ignored by makepkg, they already have enabled it in https://github.com/helix-editor/helix/blob/master/.cargo/config.toml#L11

TLDR: here is my current diff to build the package (+pkgver of course):

diff --git a/PKGBUILD b/PKGBUILD
index 04017ed..cfa8b95 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -8,6 +8,7 @@ pkgdesc="A text editor written in rust"
 url="https://helix-editor.com"
 _git="https://github.com/helix-editor/${_pkgname}.git"
 arch=(x86_64)
+options=(!lto)
 makedepends=('git' 'cargo')
 depends=()
 provides=('hx')
@@ -50,6 +51,7 @@ check() {
     export RUSTUP_TOOLCHAIN=stable
     export CARGO_TARGET_DIR=target
     cargo test --frozen --offline --workspace
+    export RUSTFLAGS="--cfg tokio_unstable"
     cargo integration-test --frozen --offline
 }

A few remarks and a working PKGBUILD, not a complete solution but might be a bit of help for the time being.

• Building manually from the master branch usually works for me with occasional test failures which is expected. Both stable and nightly work.

• I don't think that the current settings of environment variables have the desired effects. For whatever reason the build seems to always starts up with downloading toolchain 1.70.0, check your ~/.rustup/toolchains

• It is not clear to me why (!tlo) option "helps", seems rather coincidental, then tests fail with similar linking problems. In particular, when building manually lto = "thin" is used for release.

Here is my working PKGBUILD at https://0x0.st/H5vP.txt incorporating a pristine manual build into the package building process performed by makepkg. It is a shell trick but works!

Right now I don't feel like untangling the interaction between makepkg and helix' cargo build process. However, I use helix and wanted to keep close to the master branch so I just rebuild helix into my local package repo using the PKGBUILD above.

I confirm that @mekyt's solution works, at least on the initial compilation. But somewhere in the tests it spits out E0412 error while compiling.

The solution should be to add options=(!lto) in the PKGBUILD file.

I was having the same problem with a package I maintained. Still a error during the check but it's more a dependency problem due to unstable version.

error[E0412]: cannot find type `Id` in module `tokio::runtime`
   --> helix-event/src/runtime.rs:45:64
    |
45  |         parking_lot::RwLock<hashbrown::HashMap<tokio::runtime::Id, &'static T, ahash::RandomState>>,
    |                                                                ^^ not found in `tokio::runtime`
    |
note: found an item that was configured out
   --> /home/meak/.local/cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.36.0/src/runtime/mod.rs:371:21
    |
371 |         pub use id::Id;
    |                     ^^

For more information about this error, try `rustc --explain E0412`.
error: could not compile `helix-event` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
==> ERROR: A failure occurred in check().
    Aborting...

I cloned helix-editor/helix repository compiled with --release flag without issues. After testing that executable worked correctly, I stripped out the fetch and compilation phases of the PKCONFIG and redirect thecollection of the executables to the files I had just compiled. This way I have obtained a properly installed new version. What can we deduce from this? As the cloned repository can build normally, is there a minor difference in the environments between cloned and makepkgd repositories?

At a guess, from looking at the symbols, it would be extra/tree-sitter. However, none of my compiled helix binaries or ts grammars seems to link to the lib, nor do the helix docs or the rust ts lib docs mention it as a necessary dependency.

I'm hitting the same issue as @MuratOzsoyler, suggestion from this Helix discussion is that it's some Rust/libc dep that's failing, but I don't know how to turn that info into a fix.

Initial compilation fails with the following error:

error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/murat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/murat/.cargo/bin:/home/murat/.local/bin:/home/murat/.cabal/bin:/home/murat/.ghcup/bin:/home/murat/.no....
  .... many lines ....
  = note: /usr/bin/ld: /var/cache/aura/vcs/helix-git/helix-git/src/helix/target/release/deps/hx-e3df09f40b1fea98.helix_core-35178cc154b6697a.helix_core.62f28519a3a915a3-cgu.02.rcgu.o.rcgu.o: in function `<tree_sitter::Query as core::ops::drop::Drop>::drop':
          /home/murat/.cargo/git/checkouts/tree-sitter-1d6f0a99cd00d1e0/660481d/lib/binding_rust/lib.rs:2508:(.text._ZN4core3ptr39drop_in_place$LT$tree_sitter..Query$GT$17h8a7b878cfd573408E+0x1b): undefined reference to `ts_query_delete'
  .... many lines ....
          /usr/bin/ld: /home/murat/.cargo/git/checkouts/tree-sitter-1d6f0a99cd00d1e0/660481d/lib/binding_rust/lib.rs:1652:(.text._ZN11tree_sitter5Query3new17h851b3fb79dbdb265E+0x3bf8): undefined reference to `ts_query_delete'
          collect2: error: ld returned 1 exit status

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `helix-term` (bin "hx") due to previous error
==> ERROR: A failure occurred in build().

Even though compilation starts surprisingly in the middle of the tests, this patch solved it. Thank you so much for your support and effort.

Seems to be a weird interaction between the "integration_test" feature flag and the regular (non-integration) tests. I just updated the tests to more match the helix CI setup (i.e. separate test + integration-test).

Somewhat annoying side effect: it needs to compile more between unit and integration tests now