Cannot install via Cargo
CallMeCJUnderscore opened this issue · 13 comments
I installed JQ and Rustinit, following all the defaults. Then, in an elevated PowerSgell window, I typed in "cargo install rss-forwarder" as mentioned on the main page. It downloads all the packages without issue. However, when it starts compiling, it runs into an issue. After compiling a few dozen things, it issues one error and then stops completely. For some reason, trying to run with RUST_BACKTRACE=1 does not work. I am new to this, so I am simply going to post the entire error log. I'm sorry it is a lot of text, but Powershell simply gave me a lot. I have tried restarting my computer, to no avail.
The following warnings were emitted during compilation:
warning: "jemalloc support for x86_64-pc-windows-msvc is untested"
error: failed to run custom build command for jemalloc-sys v0.3.2
Caused by:
process didn't exit successfully: C:\Users\monst\AppData\Local\Temp\cargo-installTidQGO\release\build\jemalloc-sys-49e3d58dfd9e62e8\build-script-build (exit code: 101)
--- stdout
TARGET=x86_64-pc-windows-msvc
HOST=x86_64-pc-windows-msvc
NUM_JOBS=20
OUT_DIR="C:\Users\monst\AppData\Local\Temp\cargo-installTidQGO\release\build\jemalloc-sys-bbffb68d22dbd6fc\out"
BUILD_DIR="C:\Users\monst\AppData\Local\Temp\cargo-installTidQGO\release\build\jemalloc-sys-bbffb68d22dbd6fc\out\build"
SRC_DIR="C:\Users\monst\.cargo\registry\src\github.com-1ecc6299db9ec823\jemalloc-sys-0.3.2"
cargo:warning="jemalloc support for x86_64-pc-windows-msvc is untested"
OPT_LEVEL = Some("3")
TARGET = Some("x86_64-pc-windows-msvc")
HOST = Some("x86_64-pc-windows-msvc")
cargo:rerun-if-env-changed=CC_x86_64-pc-windows-msvc
CC_x86_64-pc-windows-msvc = None
cargo:rerun-if-env-changed=CC_x86_64_pc_windows_msvc
CC_x86_64_pc_windows_msvc = None
cargo:rerun-if-env-changed=HOST_CC
HOST_CC = None
cargo:rerun-if-env-changed=CC
CC = None
cargo:rerun-if-env-changed=CFLAGS_x86_64-pc-windows-msvc
CFLAGS_x86_64-pc-windows-msvc = None
cargo:rerun-if-env-changed=CFLAGS_x86_64_pc_windows_msvc
CFLAGS_x86_64_pc_windows_msvc = None
cargo:rerun-if-env-changed=HOST_CFLAGS
HOST_CFLAGS = None
cargo:rerun-if-env-changed=CFLAGS
CFLAGS = None
cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
CRATE_CC_NO_DEFAULTS = None
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
DEBUG = Some("false")
CC="C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.34.31933\bin\HostX64\x64\cl.exe"
CFLAGS="-nologo -MD -O2 -Brepro -W4"
JEMALLOC_REPO_DIR="jemalloc"
JEMALLOC_SRC_DIR="C:\Users\monst\AppData\Local\Temp\cargo-installTidQGO\release\build\jemalloc-sys-bbffb68d22dbd6fc\out\jemalloc"
cargo:rustc-cfg=prefixed
--with-jemalloc-prefix=rjem
running: "sh" "/c/Users/monst/AppData/Local/Temp/cargo-installTidQGO/release/build/jemalloc-sys-bbffb68d22dbd6fc/out/jemalloc/configure" "--disable-cxx" "--with-jemalloc-prefix=rjem" "--with-private-namespace=rjem" "--host=x86_64-pc-win32" "--build=x86_64-pc-win32" "--prefix=C:\Users\monst\AppData\Local\Temp\cargo-installTidQGO\release\build\jemalloc-sys-bbffb68d22dbd6fc\out"
--- stderr
thread 'main' panicked at 'failed to execute command: program not found', C:\Users\monst.cargo\registry\src\github.com-1ecc6299db9ec823\jemalloc-sys-0.3.2\build.rs:389:19
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile rss-forwarder v0.5.1, intermediate artifacts can be found at `C:\Users\monst\AppData\Local\Temp\cargo-installTidQGO
Windows is currently not supported, this will change with the next update in December.
I would, but I genuinely have no idea how to set up Docker to even install onto my computer. Looking up guides seems to imply I'd need to clone the repository and then set up access tokens and a lot of other stuff. There doesn't seem to be a succinct installer like for Github Desktop.
It has been many years since I last installed and used Docker on Windows. As far as I remember, it was very easy to do via an installer. It seems to be the same today.
I guess I was just doing the wrong searches since I was diving into the documentation but couldn't find that page. Thanks!
I don't get this at all. I have Docker and it's all configured, and I made a config.toml file with the feed I want, but I have no way to actually add it to the directory for the program, because according to this, Linux containers are kinda fragmented on Windows. I can open a debian image in powershell and CD to the UpperDir for the container, but then I can't find the existence of a folder called /data, and thus no place to even put config.toml, let alone try to figure out how to put it in. Because of that, trying to run the container from docker causes it to immediately error and stop running with Error while reading config: io error: No such file or directory (os error 2).
When I run ls -lah, this is all I get
Hey @BigIsBig453, theoretically, building under Windows should work with the latest release (v0.6.0-beta.0).
Maybe you can give it a try.
cargo install rss-forwarder@0.6.0-beta.0
It still doesn't work. It gets much farther along, it seems, and then gives another error.
PS C:\WINDOWS\system32> cargo install rss-forwarder@0.6.0-beta.0
Updating crates.io index
Installing rss-forwarder v0.6.0-beta.0
Compiling proc-macro2 v1.0.49
Compiling unicode-ident v1.0.6
Compiling quote v1.0.23
Compiling autocfg v1.1.0
Compiling syn v1.0.107
Compiling cfg-if v1.0.0
Compiling windows_x86_64_msvc v0.42.0
Compiling serde_derive v1.0.152
Compiling log v0.4.17
Compiling serde v1.0.152
Compiling once_cell v1.17.0
Compiling smallvec v1.10.0
Compiling parking_lot_core v0.9.5
Compiling scopeguard v1.1.0
Compiling memchr v2.5.0
Compiling winapi v0.3.9
Compiling ppv-lite86 v0.2.17
Compiling siphasher v0.3.10
Compiling pin-project-lite v0.2.9
Compiling bytes v1.3.0
Compiling futures-core v0.3.25
Compiling lock_api v0.4.9
Compiling tracing-core v0.1.30
Compiling tokio v1.24.1
Compiling itoa v1.0.5
Compiling getrandom v0.2.8
Compiling phf_shared v0.10.0
Compiling encoding_rs v0.8.31
Compiling new_debug_unreachable v1.0.4
Compiling futures-task v0.3.25
Compiling num_cpus v1.15.0
Compiling num-traits v0.2.15
Compiling slab v0.4.7
Compiling rand_core v0.6.4
Compiling indexmap v1.9.2
Compiling mac v0.1.1
Compiling futures-util v0.3.25
Compiling fnv v1.0.7
Compiling num-integer v0.1.45
Compiling windows-sys v0.42.0
Compiling httparse v1.8.0
Compiling tinyvec_macros v0.1.0
Compiling hashbrown v0.12.3
Compiling rand_chacha v0.3.1
Compiling futf v0.1.5
Compiling pin-utils v0.1.0
Compiling http v0.2.8
Compiling precomputed-hash v0.1.1
Compiling futures-channel v0.3.25
Compiling native-tls v0.2.11
Compiling futures-sink v0.3.25
Compiling utf-8 v0.7.6
Compiling rand v0.8.5
Compiling tinyvec v1.6.0
Compiling phf v0.10.1
Compiling percent-encoding v2.2.0
Compiling try-lock v0.2.4
Compiling socket2 v0.4.7
Compiling mio v0.8.5
Compiling tendril v0.4.3
Compiling schannel v0.1.21
Compiling http-body v0.4.5
Compiling serde_json v1.0.91
Compiling phf_generator v0.10.0
Compiling form_urlencoded v1.1.0
Compiling want v0.3.0
Compiling unicode-normalization v0.1.22
Compiling httpdate v1.0.2
Compiling unicode-bidi v0.3.8
Compiling parking_lot v0.12.1
Compiling winreg v0.10.1
Compiling ryu v1.0.12
Compiling tower-service v0.3.2
Compiling string_cache_codegen v0.5.2
Compiling phf_codegen v0.10.0
Compiling lazy_static v1.4.0
Compiling thiserror v1.0.38
Compiling async-trait v0.1.61
Compiling overload v0.1.1
Compiling quick-xml v0.27.1
Compiling quick-xml v0.22.0
Compiling idna v0.3.0
Compiling thread_local v1.1.4
Compiling mime v0.3.16
Compiling ipnet v2.7.1
Compiling unicode-width v0.1.10
Compiling humantime v2.1.0
Compiling base64 v0.13.1
Compiling pico-args v0.5.0
Compiling sharded-slab v0.1.4
Compiling tracing-log v0.1.3
Compiling markup5ever v0.11.0
Compiling nu-ansi-term v0.46.0
Compiling rss v2.0.1
Compiling tokio-macros v1.8.2
Compiling tracing-attributes v0.1.23
Compiling html5ever v0.26.0
Compiling url v2.3.1
Compiling thiserror-impl v1.0.38
Compiling tracing-subscriber v0.3.16
Compiling tracing v0.1.37
Compiling tokio-util v0.7.4
Compiling tokio-native-tls v0.3.0
Compiling string_cache v0.8.4
Compiling chrono v0.4.23
Compiling serde_urlencoded v0.7.1
Compiling humantime-serde v1.1.1
Compiling slack-bk v0.1.1
Compiling toml v0.5.10
Compiling h2 v0.3.15
Compiling diligent-date-parser v0.1.4
Compiling atom_syndication v0.12.0
Compiling xml5ever v0.17.0
Compiling html2text v0.4.5
Compiling hyper v0.14.23
Compiling hyper-tls v0.5.0
Compiling reqwest v0.11.13
Compiling rss-forwarder v0.6.0-beta.0
error[E0432]: unresolved import tokio::signal::unix
--> C:\Users\monst.cargo\registry\src\github.com-1ecc6299db9ec823\rss-forwarder-0.6.0-beta.0\src\main.rs:18:13
|
18 | signal::unix::{signal, SignalKind},
| ^^^^ could not find unix in signal
For more information about this error, try rustc --explain E0432.
error: could not compile rss-forwarder due to previous error
error: failed to compile rss-forwarder v0.6.0-beta.0, intermediate artifacts can be found at C:\Users\monst\AppData\Local\Temp\cargo-installIwGyWZ
PS C:\WINDOWS\system32> rustc --explain E0432
An import was unresolved.
Erroneous code example:
use something::Foo; // error: unresolved import `something::Foo`.
In Rust 2015, paths in use statements are relative to the crate root. To
import items relative to the current and parent modules, use the self:: and
super:: prefixes, respectively.
In Rust 2018 or later, paths in use statements are relative to the current
module unless they begin with the name of a crate or a literal crate::, in
which case they start from the crate root. As in Rust 2015 code, the self::
and super:: prefixes refer to the current and parent modules respectively.
Also verify that you didn't misspell the import name and that the import exists
in the module from where you tried to import it. Example:
use self::something::Foo; // Ok.
mod something {
pub struct Foo;
}
If you tried to use a module from an external crate and are using Rust 2015,
you may have missed the extern crate declaration (which is usually placed in
the crate root):
extern crate core; // Required to use the `core` crate in Rust 2015.
use core::any;
Since Rust 2018 the extern crate declaration is not required and
you can instead just use it:
use core::any; // No extern crate required in Rust 2018.
Thank you for the test and report!
I had forgotten this thing and will see if I can fix it in the next release.
I'm glad I could be of assistance! 😄
I am closing this issue. Windows support requires additional effort and I see little need for it.
In addition, Windows offers WSL since Windows 10, which makes running Linux applications easy and efficient.
Understood. Thanks for trying, morphy. I can look into running WSL on my own time.