I have the following problems:
If I execute the following command:
diesel setup
it throws me:
requires the postgres feature but it's not enabled
But my Cargo.toml looks like this:
diesel = { version = "1.4.4", features = ["postgres", "r2d2", "chrono", "uuid"] }
So now I thought well maybe I installed something wrong and when I try to run:
cargo install diesel_cli -no--default-features --features postgres
it tells me:
linking with "link.exe" failed: exit code: 1181
...
...
"libpq.lib" cant be opened
tried to reinstall, didnt work, thought it would work, gave me a new error
For linux ubuntu you need to install libq-dev
sudo apt install libpq-dev
For windows you need to either add postgres lib folder to env variables, for example:
PQ_LIB_DIR="C:\Program Files\PostgreSQL\14\lib"
or simply copy libpq.lib to
C:\Users\<username>\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib
Related
I am getting this error when I try to cross-compile some Rust; does anyone know what I should be doing?
This happens when I run cargo build --target aarch64, I get:
Compiling glib-sys v0.10.1
error: failed to run custom build command for `glib-sys v0.10.1`
...
pkg-config has not been configured to support cross-compilation.
Install a sysroot for the target platform and configure it via
PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a
cross-compiling wrapper for pkg-config and set it via
PKG_CONFIG environment variable.
I might have asked this before a year or so ago, but anyway I cannot find any answer. I have tried adding various lines to my Cargo.toml but nothing seems to help.
The relevant part of Cargo.toml has:
[target.'cfg(target_os = "android")'.dependencies]
cairo = "0.0.4"
freetype = "0.7.0"
glib = "0.14.2"
openssl = "0.10.36"
openssl-sys = {version = "0.9.66", features = ["vendored"]}
There is probably a one-line answer to this; can anyone help me please.
You could try adding feature vendored for the openssl crate.
openssl = { version = "0.10.35", features = ["vendored"] }
reference
I'm also new to rust so there may be some mistakes in my answer.
So the warning suggests that the pkg-config is not correctly set, which suggests that this is not a rust issue, it's a pkg-config issue.
If you check the doc of pkg-config, you might see there's an environment variable called PKG_CONFIG_SYSROOT_DIR which "is useful for cross compilation". What you'll need to do is to run cargo with this environment set, e.g. PKG_CONFIG_SYSROOT_DIR=/usr/x86_64-w64-mingw32/ cargo build, where /usr/x86_64-w64-mingw32 contains all the file necessary for cross build for windows (as you can see from the name).
I'm not sure how to cross compile for aarch64, and I'm not sure how to add environment variable for cargo build, but I hope my experience above can give you some hint.
I'm learning Rust from "Practical Rust Projects" by Shing Lyu. I'm now trying to build a game following the steps in Chapter 4. I'm working on Ubuntu 18.04 LTS.
After installing Rust and the Amethyst command line, I created a new project via amethyst new cat_volleyball. The next step is to run the engine using cargo run --features=vulkan
. When I do so, I get the error prompt below. Do you have suggestions on how to fix this?
error[E0433]: failed to resolve: could not find `__rt` in `quote`
--> /home/alberto/.cargo/registry/src/github.com-1ecc6299db9ec823/err-derive-0.1.6/src/lib.rs:145:63
|
145 | fn display_body(s: &synstructure::Structure) -> Option<quote::__rt::TokenStream> {
| ^^^^ could not find `__rt` in `quote`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0433`.
error: could not compile `err-derive`.
warning: build failed, waiting for other jobs to finish...
TL;DR Edit the Cargo.lock manually, please check the title below : How to force cargo to use yanked version of sub-dependency (for the proper steps)
Why this happens ?
This happened because in err-derive-0.1.6 is using quote-1.0.2 as dependency but in it's cargo.toml dependency declared like this:
[dependencies.quote]
version = "1.0.2"
This means cargo will use the latest minor update, so if quote-1.0.3 is out then cargo will use 1.0.3 instead 1.0.2. Please check caret-requirement. The problem in here is quote-1.0.3 breaks backward compatibility that comes from quote-1.0.2. In this case quote
How to force cargo to use specific version of sub-dependency
You can fix this issue by forcing the sub-dependency to use compatible version for your dependency.
This command will do it :
> cargo update -p quote --precise 1.0.2
How to force cargo to use yanked version of sub-dependency
Looks like quote-1.0.2 was yanked from crates.io, so command up above will not work because cargo will not be able to find the yanked version on crates.io . Since cargo update modifies the cargo.lock we can do it manually. To start clean :
Remove Cargo.lock
Run cargo update ( this will generate latest version Cargo.lock )
Edit Cargo.lock
Find the incompatible version of package in cargo.lock which is quote-1.0.3, It should look like this:
[[package]]
name = "quote"
version = "1.0.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
"proc-macro2 1.0.9 (registry+https://github.com/rust-lang/crates.io-index)",
]
then simply change version to the compatible version in our case it is "1.0.2"
[[package]]
name = "quote"
version = "1.0.2"
After doing that do not run cargo update again, it will overwrite your changes and you'll not able to compile your project. Please remember this is a workaround for being able to continue the development, there is a reason to yank crates, do not use it in production it is best to wait dependent crates to update itself.
Note : In some cases you may get an error after editing cargo.lock:
error: Found argument 'Cargo.lock' which wasn't expected, or isn't valid in this context
#albus_c fixed this by doing :
A note for posterity: I fixed the issue removing rustc
(sudo apt remove rustc) and reinstalled as recommended on the Rust website,
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
After that everything worked fine.
First, delete and recreate a fresh virtualenv. This works fine:
rm -rf ~/.virtualenvs/test
python3 -m venv ~/.virtualenvs/test
As soon as I try to install the pip library ansible, I get clang compilation errors. There is a large amount of compiler output to the console that I'm editing out for simplicity. I suspect this isn't an issue with my local environment, but a software compatibility issue with Python 3.7.
vex --path ~/.virtualenvs/test pip install ansible
<snip>
ext/_yaml.c:24143:21: error: no member named 'exc_type' in 'struct _ts'
*type = tstate->exc_type;
~~~~~~ ^
<snip>
51 warnings and 15 errors generated.
error: command 'clang' failed with exit status 1
This looks like an issue with cython. There are many similar issues reported on GitHub for some famous libraries like scikit-learn, pandas etc. Considering creating an issue in Ansible repo.
Also see:
https://github.com/cython/cython/issues/1955
Following this example:
$ cargo build --verbose
Updating registry `https://github.com/rust-lang/crates.io-index`
failed to parse registry's information for: wayland-client
Caused by:
the given version requirement is invalid
This happens on every example and builds from other repos. I am running Ubuntu 16.04 LTS and I installed Cargo and Rustc through apt. Using versions: rustc 1.7.0 and cargo 0.8.0.
My Cargo.toml from the example:
[package]
name = "spinning-square"
version = "0.1.0"
authors = [
"TyOverby <ty#pre-alpha.com>",
"Nikita Pekin <contact#nikitapek.in>"
]
[[bin]]
name = "spinning-square"
[dependencies]
piston = "0.31.1"
piston2d-graphics = "0.21.1"
pistoncore-glutin_window = "0.35.0"
piston2d-opengl_graphics = "0.40.0"
I ended up using
$ sudo apt install libsdl2-dev
and then it started to work. However, I do not know if this is the true solution because I removed libsdl2 and it continued to work after that. A theory of mine is that because Piston uses sdl2, it corrected something to make it work, maybe.
If anyone has found a better solution for the next guy to have issues, I'll leave this post unanswered for a while longer.
I am on an amd64 Debian machine, and am trying to build a x86_64-unknown-linux-musl executable. I have this in my Cargo.toml:
[dependencies]
curl = "0.4"
When I run cargo build --target=x86_64-unknown-linux-musl I get
this:
error: failed to run custom build command for `libz-sys v1.0.10`
process didn't exit successfully: `/tmp/foo/target/debug/build/libz-sys-c20da5f29c41e515/build-script-build` (exit code: 101)
--- stdout
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-unknown-linux-musl")
debug=true opt-level=0
HOST = Some("x86_64-unknown-linux-gnu")
TARGET = Some("x86_64-unknown-linux-musl")
TARGET = Some("x86_64-unknown-linux-musl")
HOST = Some("x86_64-unknown-linux-gnu")
CC_x86_64-unknown-linux-musl = None
CC_x86_64_unknown_linux_musl = None
TARGET_CC = None
CC = None
HOST = Some("x86_64-unknown-linux-gnu")
CROSS_COMPILE = None
TARGET = Some("x86_64-unknown-linux-musl")
HOST = Some("x86_64-unknown-linux-gnu")
CFLAGS_x86_64-unknown-linux-musl = None
CFLAGS_x86_64_unknown_linux_musl = None
TARGET_CFLAGS = None
CFLAGS = None
running: "./configure" "--prefix=/tmp/foo/target/x86_64-unknown-linux-musl/debug/build/libz-sys-e109627694e9981e/out"
Compiler error reporting is too harsh for ./configure (perhaps remove -Werror).
** ./configure aborting.
--- stderr
thread 'main' panicked at 'failed to run successfully: exit code: 1', /home/tshepang/.cargo/registry/src/github.com-1ecc6299db9ec823/libz-sys-1.0.10/build.rs:189
When I re-run it:
error: failed to run custom build command for `openssl-sys v0.9.6`
process didn't exit successfully: `/tmp/foo/target/debug/build/openssl-sys-ac9c042b062dad1d/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at '
Could not find directory of OpenSSL installation, and this `-sys` crate cannot
proceed without this knowledge. If OpenSSL is installed and this crate had
trouble finding it, you can set the `OPENSSL_DIR` environment variable for the
compilation process.
If you're in a situation where you think the directory *should* be found
automatically, please open a bug at https://github.com/sfackler/rust-openssl
and include information about your system as well as this message.
$HOST = x86_64-unknown-linux-gnu
$TARGET = x86_64-unknown-linux-musl
openssl-sys = 0.9.6
All works well when I build natively, i.e. cargo build --target=x86_64-unknown-linux-gnu.
Searching around, I learned about an environment variable, PKG_CONFIG_ALLOW_CROSS:
PKG_CONFIG_ALLOW_CROSS=true cargo build --target=x86_64-unknown-linux-musl
In doing that, I also found that I was missing the Debian package
named libcurl4-openssl-dev.
Running ldd target/target/x86_64-unknown-linux-musl/debug/foo
indicated the executable is dynamically linked, then searching
further, I learned about another environment variable,
PKG_CONFIG_ALL_STATIC:
PKG_CONFIG_ALL_STATIC=true PKG_CONFIG_ALLOW_CROSS=true cargo build --target=x86_64-unknown-linux-musl
That revealed a whole bunch of missing deps, all of which (luckily)
had Debian dependencies. But installing all of them did not help, as,
in the end, I was still sitting with an executable that wasn't
statically linked .
I gave in and ended up using cross:
cargo install cross
cross build --target=x86_64-unknown-linux-musl
This was just too easy, and you will find the executable in target/x86_64-unknown-linux-musl/debug.
The curl crate depends (directly or indirectly) on the two crates libz-sys and openssl-sys.
A crate whose name ends in "-sys" is generally a set of FFI (foreign function interface) bindings to a native C library.
Building such a "-sys" crate requires linking to the native library. If your target is x86_64-unknown-linux-musl, then you must link to a native library built against musl, not glic. However, most of the packages you will find in the repositories of your distribution provide libraries built against glibc.
The solution is to build yourself the libraries you need, linking to musl instead of glibc.
I don't have access to a Debian installation, but on Ubuntu 16.04 this looks like this for OpenSSL:
# this package provides the "musl-gcc" wrapper
apt-get install musl-tools
# you will also need these, if they are not installed yet
apt-get install pkg-config xutils-dev build-essential
# Download and build OpenSSL against musl
VERS=1.0.2j
export CC=musl-gcc
export MUSL_PREFIX=/usr/local/musl
export C_INCLUDE_PATH="$MUSL_PREFIX/include/"
curl -O https://www.openssl.org/source/openssl-$VERS.tar.gz
tar xvzf openssl-$VERS.tar.gz
cd openssl-$VERS
./config --prefix "$MUSL_PREFIX"
make depend
make
sudo make install
export OPENSSL_DIR=/usr/local/musl/
export OPENSSL_STATIC=1
Once you have one the same for libz (I haven't tried to built it), you should then be able to build your crate:
cargo build --target=x86_64-unknown-linux-musl
and the resulting binary will be in target/x86_64-unknown-linux-musl/debug/<binary_name>
The cross tool does basically this, but inside a Docker container as to keep your host machine clean.
The binary produced by this build should be statically linked, and not depend even on glibc. This also means that it will be bigger* and that you will need to take care yourself of upgrading any dependency (especially OpenSSL) if a security issue is found in one of them.
*You may want to use strip on the released binary.