I use multiple rust packages in my desktop. To install those packages i use
cargo install fd-find sd ripgrep bat exa git-delta du-dust choose alacritty nu tealdeer broot
To update those packages , i use cargo-update sub-command.
cargo install cargo-update
cargo install-update -a
Is there any command or sub-command or technique i can use to download only pre-compiled binaries (instead of downloading the source code and compiling in my machine) to install or update rust crates.
Since crates can be compiled with or without certain features which result in different code, there isn't any mechanism to up- or download pre-compiled crates.
On top of that, the list of supported targets is very long which would make it very likely that the platform you're on doesn't have pre-compiled binaries.
Finally, there'd need to be additional mechanisms to sign the code and verify that the pre-compiled code matches the source code.
So all in all there are several obstacles that render implementing this impractical.
Related
I am trying to build gstreamer using gst-build: https://gitlab.freedesktop.org/gstreamer/gst-build
Glib is one of the subprojects it is downloading and compile. But I am thinking of replacing it with the previously compiled version. How should I do it in the cross-file? Or there is no way other than hacking meson.build
Thanks
Regrds
It depends on the discovery methods that dependency supports, if it uses pkg-config, it's probably as easy as setting [built-in options]:pkg_config_path in your cross file (or the various $PKG_CONFIG_PATH environment variables) to include the pkg-config file. I'm pretty sure that glib uses pkg-config.
I have dependencies in my code that requires libc. When building (cargo build --release) on Ubuntu 20.04 (glibc 2.31) the resulting executable doesn't run on CentOS 7 (glibc 2.17). It throws an error saying it requires GLIBC 2.18.
When build the same code on CentOS 7 the resulting executable runs on CentOS 7 and Ubuntu 20.04.
Is there a way to control which GLIBC version is required to build this version on Ubuntu 20.04 too?
If your project does not depend on any native libraries, then probably the easiest way would be to use the x86_64-unknown-linux-musl target.
This target statically links against MUSL Libc rather than dynamically linking against the system's libc. As a result it produces completely static binaries which should run on a wide range of systems.
To install this target:
rustup target add x86_64-unknown-linux-musl
To build your project using this target:
cargo build --target x86_64-unknown-linux-musl
See the edition guide for more details.
If you are using any non-rust libraries it becomes more difficult, because they may be dynamically linked and may in turn depend on the system libc. In that case you would either need to statically link the external libraries (assuming that is even possible, and that the libraries you are using will work with MUSL libc), or make different builds for each platform you want to target.
If you end up having to make different builds for each platform, a docker container would be the easiest way to achieve that.
Try cross.
Install it globally:
cargo install cross
Then build your project with it:
cross build --target x86_64-unknown-linux-gnu --release
cross take the same arguments as cargo but you have to specify a target explicitly. Also, the build directory is always target/{TARGET}/(debug|release), not target/(debug|release)
cross uses docker images prebuilt for different target architectures but nothing stops you from "cross-compiling" against the host architecture. The glibc version in these docker images should be conservative enough. If it isn't, you can always configure cross to use a custom image.
In general, you need to build binaries for a given OS on that OS, or at the very least build on the oldest OS you intend to support.
glibc uses symbol versioning to preserve the behavior of older programs while adding support for new functionality. For example, a newer version of pthread_mutex_lock may support lock elision, while the old one would not. You're seeing this error because when you link against libc, you link against the default version of the symbol if a version isn't explicitly specified, and in at least one case, the version you linked against is from glibc 2.18. Changing this would require recompiling libstd (and the libc crate, if you're using it) with custom changes to pick the old versioned symbols, which is a lot of work for little gain.
If your only dependency is glibc, then it might be sufficient to just compile on CentOS 7. However, if you depend on other libraries, like OpenSSL, then those just aren't compatible across OS versions because their SONAMEs differ, and there's no way around that. So that's why generally you want to build different binaries per OS.
I am trying to cross-compile my Rust project on Mac OS to Linux using cargo build --target=x86_64-unknown-linux-musl.
I installed the binary for Linux + musl cross-compilation on mac using brew install FiloSottile/musl-cross/musl-cross as I would ideally want a standalone binary.
I also installed the target using rustup target add x86_64-unknown-linux-gnu
And I have the following in my .cargo/config:
[target.x86_64-unknown-linux-musl]
linker = "x86_64-linux-musl-gcc"
However, I ran into issues with 2 libraries - sqlite3 and pcap:
= note: /usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lsqlite3
/usr/local/Cellar/musl-cross/0.9.8/libexec/bin/../lib/gcc/x86_64-linux-musl/6.4.0/../../../../x86_64-linux-musl/bin/ld: cannot find -lpcap
collect2: error: ld returned 1 exit status
I was able to solve the sqlite3 linker issue by adding features = ["bundled"] to my Cargo.toml file (similar to what is described here - https://users.rust-lang.org/t/linker-cannot-find-lsqlite3/23230/18) as that likely built it from source (which was great) but when I tried doing the same with pcap, it gave the following error:
the package `myProject` depends on `pcap`, with features: `bundled` but `pcap` does not have these features.
After reading somewhere I also tried (with low hopes) of providing the path to the installed libpcap on mac using RUSTPATH='-L/...' cargo build ... but that resulted, of course in undefined symbol errors.
Any ideas how can I get past this issue and cross compile my Rust project into a statically linked binary on macos to run on linux?
Cross compilation does not magically take care of libraries. You cannot just say "I want musl" and have something take care of all your dependencies.
The error message you are seeing is telling you exactly this: it cannot find libsqlite3 and libpcap.
The reason the error for sqlite disappears is because your sqlite library has a bundled feature, which replaces the linking with a built-in sqlite client. This, however, also requests the pcap bundled feature, which does not exist.
You have two options:
If you do not mind the performance loss in the bundled sqlite client, change your feature definition to target the feature of the dependency requiring sqlite
If you want the raw library itself, you will have to compile it for musl
No matter what happens, you will need to cross-compile libpcap for musl with the default sysroot provided by your musl compiler. As this varies per library, you will need to consult the libpcap documentation. once you have done so, you should be able to use the -lpcap flag, and the error will resolve itself.
I just installed Rust with rustup on MacOS and noticed that there are two rustc and two cargo binaries:
~/.cargo/bin/rustc (cargo)
~/.rustup/toolchains/stable-x86_64-apple-darwin/bin/rustc (cargo)
Their versions are exactly the same, but diff shows there exists some difference. So why are there two different rustc (cargo) binaries and which one should I use?
The reason there are two files named rustc is because rustup is a toolchain multiplexer. It lets you install many versions of Rust and easily switch between them.
The binary installed at ~/.cargo/bin/rustc proxies to the current toolchain that you have selected. Each installed compiler is kept under the toolchains directory.
Although the compiler in the toolchains directory appears to be a smaller file, that's only because it's dynamically linked instead of statically linked.
More information can be found on rustup's README.
Background:
I've been using the gloss library for some simple diagram work. But when it came time for something more interactive, I found I wanted a more powerful library. After doing some research, I decided that I liked the features of the SDL library and wanted to try to install the Haskell bindings for it. I have to this point been unsuccessful.
Part 1:
How do I install and configure the SDL binaries so that they can be used by the Haskell bindings?
Part 2:
Which one of the numerous and ill documented SDL packages on Hackage it the current preferred binding in the community? How do I get that package to install correctly?
Part 3: (Optional)
If SDL is not a good fit for haskell development what is the preferred alternative?
I am going to answer your question for SDL2 (should also work for SDL1 with some modifications).
Install pkg-config for Windows
(How to install pkg config in windows?)
This tool is very important. It is used by various Cabal packages to search for libraries and contains directions for linking and compiling.
Download the SDL development libraries for Windows/MinGW:
http://libsdl.org/release/SDL2-devel-2.0.3-mingw.tar.gz
If you have installed the 32-bit version of the Haskell platform, extract the folder i686-w64-mingw32
For 64-bit versions extract x86_64-w64-mingw32
You will get following layout:
include
share
bin
lib
"Register" the library with pkg-config.
Either copy lib/pkgconfig/sdl2.pc into the folder of your pkg-config.exe or modify/create the PKG_CONFIG_PATH accordingly. Check that you set up everything correctly:
C:\pkg-config --list-all | grep sdl2
sdl2 sdl2 - Simple DirectMedia Layer is a cross-platform multimedia
library designed to provide low level access to audio, keyboard,
mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer.
Add the bin folder to your PATH environment variable.
Install the sdl2 package via the Cabal installer and tell Cabal where to find your libraries.
Example:
cabal install sdl2 --extra-include-dirs=C:\lib\sdl2\include --extra-lib-dirs=C:\lib\sdl2\lib\
To test my installation, I have written a small example:
https://github.com/ftl2014/haskell-stuff/blob/master/sdl/
Caveat emptor:
If Cabal complains about a "missing" library, it might be the case that library was actually found but it is incompatible (e.g. using a 32-bit instead of a 64-bit version) or corrupt. The same is true for header files.
For some reason, Cabal complained about not finding SDL.h, and I had to use the headers in the root include folder of the archive (but maybe I was just drinking too much Kool-aid).
I wasn't able to get it to install on my system. Here's what I tried. Strangely, I was able to get configure find the header files but not the actual binary.
Let's try it. I have installed the new 2014 Haskell Platform.
cabal install sdl
Configuring SDL-0.6.5...
setup.exe: The package has a './configure' script. This requires a Unix
compatibility toolchain such as MinGW+MSYS or Cygwin.
Failed to install SDL-0.6.5
GHC in the Haskell Platform comes with MinGW, so we probably need to install MSYS. The MSYS page says to install minggw get, which says to install
An automated GUI installer assistant called mingw-get-setup.exe is the preferred method for first time installation. This will guide you through the setup of the mingw-get installer proper; you will then use this to perform further package installations, and to manage your installation.
Running the installer with the default options gives us the following screen:
We already have mingw from installing the Haskell platform, so we'll click on only the last item in the list, msys-base, and select "Mark for Installation". Then, in the "Installation" menu in the top left, select "Apply Changes". This asks if it is ok to proceed, and we select "Apply"
This installer didn't put msys-base in the path, we can add it to the path, and try installing sdl again
set PATH=C:\MinGW\msys\1.0\bin\;%PATH%
cabal install sdl
Configuring SDL-0.6.5...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking for sdl-config... no
checking for sdl11-config... no
configure: error: *** SDL not found! Get SDL from www.libsdl.org.
If you already installed it, check it's in the path. If problem remains,
please send a mail to the address that appears in ./configure --version
indicating your platform, the version of configure script and the problem.
Failed to install SDL-0.6.5
We need to download and install libsdl. I went to the libsdl download page and downloaded the Win32 development libraries, SDL-devel-1.2.15-mingw32.tar.gz. I extracted this archive (7-zip can extract both tar archives and gzip compressed files). For convenience, I moved the SDL-1.2.15 directory to c:. We'll add this to the path, as suggested by the previous error, and try again
set PATH=C:\SDL-1.2.15\bin\;%PATH%
cabal install sdl
* Missing (or bad) header file: SDL/SDL.h
* Missing C library: SDL
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
We can make part of this error go away by adding the suggested --extra-include-dirs flag, but still get the following error
cabal install sdl --extra-include-dirs=c:\SDL-1.2.15\include
* Missing C library: SDL
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
Adding the --extra-lib-dirs flag with c:\SDL-1.2.15\bin or C:\SDL-1.2.15\lib or c:\SDL-1.2.15 failed to fix this problem.