I'm trying to compile the sample code from the docx crate:
# Cargo.toml
[dependencies]
docx = "1.1.2"
//! main.rs
use docx::document::Paragraph;
use docx::DocxFile;
fn main() {
let docx = DocxFile::from_file("origin.docx").unwrap();
let mut docx = docx.parse().unwrap();
let para = Paragraph::default().push_text("Lorem Ipsum");
docx.document.push(para);
docx.write_file("origin_appended.docx").unwrap();
}
This is the full error I'm getting:
Compiling bzip2-sys v0.1.11+1.0.8
Compiling jetscii v0.4.4
Compiling quote v1.0.21
Compiling time v0.1.44
error: generic parameters may not be used in const operations
--> /home/thwart/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.4/src/simd.rs:109:13
|
109 | T::CONTROL_BYTE,
| ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
|
= note: type parameters may not be used in const expressions
error: generic parameters may not be used in const operations
--> /home/thwart/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.4/src/simd.rs:148:13
|
148 | T::CONTROL_BYTE,
| ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
|
= note: type parameters may not be used in const expressions
error: could not compile `jetscii` due to 2 previous errors
Why is Rust compiling jetscii? How do I fix this error?
This is caused by an unfortunate combination of a slightly-incompatible Rust update and old crates. The docx library depends on jetscii via this dependency tree:
docx v1.1.2
└── strong-xml v0.5.0
└── jetscii v0.4.4
You can view jetscii issue #56, jetscii pull request #39, and rust-lang/stdarch issue #248 for more info, but the basic summary is (courtesy of shepmaster):
TL;DR, older versions of Rust exposed the SIMD intrinsics in one way, that was changed, and a small number of crates (such as Jetscii) were affected.
The jetscii and strong-xml have long since been updated to accommodate this change but docx has not (no updates in over two years).
To workaround this issue your options are limited:
use Rust version 1.53
update docx with newer dependencies yourself
change libraries (consider docx-rs or docx-rust)
Related
When trying to follow the instructions of the pathfinder library, i.e:
cd demo/native
cargo run --release
I get errors due to the compilation of the dependency winit version 0.19.3:
error[E0308]: mismatched types
--> /Users/yairchu/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.19.3/src/platform/macos/view.rs:209:9
|
205 | extern fn has_marked_text(this: &Object, _sel: Sel) -> BOOL {
| ---- expected `bool` because of return type
...
209 | (marked_text.length() > 0) as i8
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `bool`, found `i8`
If I try changing the version used to the latest (which works fine for me) by changing Cargo.toml:
--- a/demo/native/Cargo.toml
+++ b/demo/native/Cargo.toml
## -43,7 +43,7 ## rev = "f3df871ac8c3926fe9106d86a3e51e20aa50d3cc"
[dependencies.winit]
-version = "<0.19.4" # 0.19.4 causes build errors https://github.com/rust-windowing/winit/pull/1105
+version = "0.27.2"
I still get the same errors!
Interestingly, I notice this in cargo's output:
Compiling winit v0.19.3
Compiling winit v0.27.2
It appears to now be building both the version I specified and the old version.
I'm lost. Also using --verbose didn't help elucidate why cargo chooses to build this specific dependency.
Is it using two versions of the same library in one executable?
How can I find out why cargo chooses to build this library? (so that I can update it to the working version)
Thanks! Rust noob
How can I find out why cargo chooses to build this library?
cargo tree elaborates on whose dependency is each sub-dependency.
Is it using two versions of the same library in one executable?
It is.
You can depend on different versions of the the same crate. This can be useful if you want to use one version of the dependency, but one of your own dependencies uses another version.
(thanks #Masklinn for the answers in the comments!)
I've been working with parity's contracts node (latest version) and the substrate template node (tag polkadot-v0.9.18), both present the same issue when compiling.
I have a very simple pallet that stores certain items. The main structure is the following:
#[pallet::storage]
#[pallet::getter(fn items)]
/// 'Mapping' Item ID -> Item Data
pub(crate) type Items<T: Config> = StorageMap<_, Twox64Concat, T::Hash, Item<T>>;
I was trying to add a simple RPC method following this guides https://core.tetcoin.org/recipes/custom-rpc.html#rpc-to-call-a-runtime-api and https://core.tetcoin.org/recipes/runtime-api.html
I also checked some projects that already have custom RPC calls implementations, like de subsocial node and I have pretty much the same structure and dependencies.
My rpc method does nothing but return a number 2 just to make sure it works, but it doesn't. This is what the pallets directory looks like:
pallets directory
When I try to compile, the following error shows
error: the wasm32-unknown-unknown target is not supported by default, you may need to
enable the "js" feature. For more information see:
https://docs.rs/getrandom/#webassembly-support
I don't even use that module, but I've read that it is used somewhere as an indirect dependency.
I'm compiling my project with the following command
cargo build --release
Checking the documentation regarding the 'getrandom' crate issue, I added the following dependency in the Cargo.toml (I tried adding it in every Cargo.toml within the project, individually, by pairs, ...)
getrandom = { version = "0.2", features = ["js"] }
Then another error shows up:
error: failed to run custom build command for secp256k1-sys v0.4.1
Which again, doesn't make any sense to me.
The project itself has nothing but the node template base and a new pallet that implements a create and transfer function. Without the RPC implementation, it works perfectly using the Polkadot App, but as soon as I include the custom rpc, it just doesn't compile.
This is my rust configuration (rustup show)
installed toolchains
--------------------
stable-x86_64-apple-darwin (default)
nightly-2021-11-04-x86_64-apple-darwin
nightly-x86_64-apple-darwin
active toolchain
----------------
stable-x86_64-apple-darwin (default)
rustc 1.59.0 (9d1b2106e 2022-02-23)
I haven't found anyone who is dealing with this kind of issue, and I don't know where the problem might be.
This is the first issue logs:
error: the wasm32-unknown-unknown target is not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
--> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.5/src/lib.rs:229:9
|
229 | / compile_error!("the wasm32-unknown-unknown target is not supported by \
230 | | default, you may need to enable the \"js\" feature. \
231 | | For more information see: \
232 | | https://docs.rs/getrandom/#webassembly-support");
| |________________________________________________________________________^
error[E0433]: failed to resolve: use of undeclared crate or module `imp`
--> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.5/src/lib.rs:256:5
|
256 | imp::getrandom_inner(dest)
| ^^^ use of undeclared crate or module `imp`
For more information about this error, try `rustc --explain E0433`.
error: could not compile `getrandom` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed
Current status (to reproduce error): https://github.com/andresvsm/substrate-pallet-rpc/tree/items-branch
Sometimes, you can get this error from a deep dependency of another dependency, e.g. when you really build for a wasm32-unknown-unknown target, and getrandom is linked but even not used. It can be fixed (worked around) with the following trick:
In Cargo.toml, add this line:
[dependencies]
getrandom = {version = "0.2", default-features = false, features = ["custom"]}
It tells the compiler to use a dummy implementation inside of getrandom.
Fixed for me when I added "default features = 'false'" into my Cargo.toml under the dependency in question.
I have been trying to learn the Rust language. I have managed to create some simple command line applications but now I am moving on to see if I can create an application that uses a graphical interface. I have looked into several GUI libraries including iced and the Qt API, but they have not worked out. I have most recently landed on GTK. I grabbed the example from the gtk crate documentation at
https://gtk-rs.org/gtk3-rs/stable/latest/docs/gtk/
There is no information on that page on what to put into the Cargo.toml file so I have been trying to figure it out. The answers I have found on the web so far have been no help at all. So I went to crates.io and grabbed the the latest version of the gtk crate, 0.14.3, and put that into the toml.
[package]
name = "gtkhello"
version = "0.1.0"
authors = ["brian"]
edition = "2018"
[dependencies]
gtk = "0.14.3"
Here is the example program, copied unaltered from the documentation.
use gtk::prelude::*;
use gtk::{Application, ApplicationWindow};
fn main() {
let app = Application::builder()
.application_id("org.example.HelloWorld")
.build();
app.connect_activate(|app| {
// We create the main window.
let win = ApplicationWindow::builder()
.application(app)
.default_width(320)
.default_height(200)
.title("Hello, World!")
.build();
// Don't forget to make all widgets visible.
win.show_all();
});
app.run();
}
When I attempt to build this with cargo the compilation of the library fails. I do not know how to continue if the library itself will not compile. Here are the errors:
[brian#localhost gtkhello]$ cargo build
Compiling glib-macros v0.14.1
Compiling gdk-pixbuf-sys v0.14.0
error[E0658]: `#[doc(alias)]` is experimental
--> /home/brian/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-macros-0.14.1/src/clone.rs:202:1
|
202 | #[doc(alias = "get_full_ident")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #50146 <https://github.com/rust-lang/rust/issues/50146> for more information
error[E0658]: `#[doc(alias)]` is experimental
--> /home/brian/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-macros-0.14.1/src/clone.rs:248:1
|
248 | #[doc(alias = "get_keyword")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #50146 <https://github.com/rust-lang/rust/issues/50146> for more information
error[E0658]: `#[doc(alias)]` is experimental
--> /home/brian/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-macros-0.14.1/src/clone.rs:366:1
|
366 | #[doc(alias = "get_expr")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #50146 <https://github.com/rust-lang/rust/issues/50146> for more information
error[E0658]: `#[doc(alias)]` is experimental
--> /home/brian/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-macros-0.14.1/src/clone.rs:413:1
|
413 | #[doc(alias = "get_return_kind")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #50146 <https://github.com/rust-lang/rust/issues/50146> for more information
error[E0658]: `#[doc(alias)]` is experimental
--> /home/brian/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-macros-0.14.1/src/clone.rs:474:5
|
474 | #[doc(alias = "get_closure")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #50146 <https://github.com/rust-lang/rust/issues/50146> for more information
error[E0658]: `#[doc(alias)]` is experimental
--> /home/brian/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-macros-0.14.1/src/clone.rs:579:1
|
579 | #[doc(alias = "get_closure")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #50146 <https://github.com/rust-lang/rust/issues/50146> for more information
Compiling gdk-sys v0.14.0
error: aborting due to 6 previous errors
For more information about this error, try `rustc --explain E0658`.
error: could not compile `glib-macros`.
To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed
I went to the link that was suggested in the error messages for the issue and it ends with:
bors closed this in 57c5f40 on Sep 14, 2020
So I guess my question has several facets. What do I put into the Cargo.toml file to make this example work? How do I find that information in the future should I branch out from this simple example? How do I get around a required crate that will not compile? How do I tell cargo that experimental code is OK by me?
The biggest question is "What am I missing?"
The referenced feature was previously unstable, but stabilized in version 1.48.0. So, minimal supported Rust version for gtk-rs is at least 1.48.0.
In general, if you see some crate failing to compile with reference to "unstable features", but the corresponding tracking issue is already closed, this usually means that your compiler version is older then the minimal supported by the crate in question. If the tracking issue is open, i.e. the feature is not stabilized yet, the crate might be nightly-only - in this case you have to add the necessary toolchain with rustup install nightly and then either set is as global default via rustup default nightly, or set an override (the easiest way is with rustup override nightly) for current project only.
I've created a program which works as expected:
extern crate base64;
// decode base64
let bytes = base64::decode(res[1]).unwrap();
[dependencies]
base64 = "0.13.0"
serde_json = "1.0.64"
When I add this code to Webassembly for an Envoy filter with base64 lib , I get the error:
INFO: From Compiling Rust cdylib filter (1 files):
error[E0463]: can't find crate for `base64`
--> filter.rs:1:1
|
1 | extern crate base64;
| ^^^^^^^^^^^^^^^^^^^^ can't find crate
This playground works with the default "Run" button, but this playground doesn't work if you run it as "Wasm". You will get the error which described above. Both links have the exact same code.
my cargo.toml look like following
[dependencies]
base64 = "0.13.0"
serde_json = "1.0.64"
serde = { version = "1.0.126", features = ["derive"] }
It seems that web-assemble rust doesn't support base64 lib (as far as I understand it as I'm new to Rust)
My question: which options I have to overcome this issue ?**
How to reproduce the full scenario (quite simple with the following
steps)
Download wasme (which generate a rust project)
curl -sL https://run.solo.io/wasme/install | sh
Init skeleton project
wasme init ./new-filter ---> choose rust
Add to the filter.rs file the base64 code
Run the build
wasme build rust -t mytest . (needs docker)
More info about wasme etc could be found here
And you will see the error which I provided above and is the same as the run the playground with WASM
If something is missing or isn't clear please let me know and I'll add
I don't think this is an issue with the base64 crate itself; I've been able to use it both in a Rust project targeting browser (via wasm-bindgen) and in a project creating an envoy filter (using the proxy-wasm-rust-sdk crate).
I think the issue you are experiencing has to do with the way dependencies are declared in wasme specifically - see the autogenerated BUILD file in your project, you might need to adjust it.
(And the solo.io folks often provide focused help at their wasm slack channel.)
I added following lines to the cargo.toml of my project in order to benchmark my code:
[dev-dependencies]
criterion = "0.3"
[[bench]]
name = "samples"
harness = false
After running cargo bench, I get a lot of errors similar to the following:
Compiling criterion v0.3.4
error[E0603]: module `export` is private
--> C:\Development\Rust\cargo\registry\src\github.com-1ecc6299db9ec823\criterion-0.3.4\src\connection.rs:201:17
|
201 | #[derive(Debug, Deserialize)]
| ^^^^^^^^^^^ private module
|
note: the module `export` is defined here
--> C:\Development\Rust\cargo\registry\src\github.com-1ecc6299db9ec823\serde-1.0.123\src\lib.rs:275:5
|
275 | use self::__private as export;
The error message looks to me that there is a problem between serde and criterion. But I did not find this error message in either project issues, so there may be a hidden reason in my workspace.
Some additional information:
the project is compiled using the nightly toolchain
there is just one explicit dependency (proc macros) in the cargo.toml which transitively references syn, quote and proc-macro2
The serde version and serde_derive version in your dependency graph are mismatched. You need to use cargo update to bring them in sync. The two must have the identical version number always.