I have updated a meta-layer for an application based on RPI3B to Yocto sumo release. The reason why I am using now RPI3B+ (instead of RPI3B).
When doing so, I run into a problem that Boost library 1.66.0 (in sumo) is not compatible with the one i used in previous build 1.64.0.
Is there a way to force Yocto in my configuration to start using boost 1.64.0 instead of the 1.66.0 ?
Yocto allows to choose preferred version of recipe with using - PREFERRED_VERSION, add into config file line:
PREFERRED_VERSION_boost = "1.64.0"
Proof:
$ bitbake -s | grep -e Preferred -e ^boost\\s
Recipe Name Latest Version Preferred Version
boost :1.67.0-r0 :1.64.0-r0
Related
I am developing a Linux image operating system using Yocto Project.
I am using SUMO branch (Yocto Project 2.5).
In order to install the boost library in my Linux image, I added this line to the local.conf file :
IMAGE_INSTALL_append = " boost"
But I discover that the default version installed is Boost 1.66.0.
Under meta/recipes-support/boost directory I can find three files :
recipes-support/boost/boost_1.66.0.bb
recipes-support/boost/boost-1.66.0.inc
recipes-support/boost/boost.inc
I think that those are the recipes for this library.
I need to use version 1.70.0 because I have an application coded using this version.
I don't know how to modify these recipes in order to have the desired version, or is there another method to use ? I don't find any helpful tips on the internet. Can you help me please ?
Thank you!
take a look at the openembedded layer index. There you'll find the recipe for boost 1.72. If this recipe doesn't depend on any other components of your system (like gcc version), you'll be able to add this recipe in your own layer. Then, in your build/local.conf, after IMAGE_INSTALL_append = "<YOUR_OTHER_PGS> boost" set the preferred version for boost by adding PREFERED_VERSION_boost="1.72.0" to the file and rerun bitbake.
I hope this helps.
Is there any way to cross compile gcc and gdb using the bitbake command in YOCTO project?
If I get you correctly you want to add gcc and gdb to the image.
The easiest and cleanest solution I know is to enable them via EXTRA_IMAGE_FEATURES.
Typically, you configure this variable in your local.conf file, which is found in the Build Directory. Although you can use this variable from within a recipe, best practices dictate that you do not. [1]
EXTRA_IMAGE_FEATURES = "tools-sdk tools-debug"
[1] http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-EXTRA_IMAGE_FEATURES
To create the image-based SDK, For example, run this:
$ bitbake core-image-full-cmdline -c populate_sdk
With that, the SDK is created based on the core-image-full-cmdline image.
After it is done, the binary script can be found at /build/tmp/deploy/sdk/poky-eglibc-x86_64-core-image-full-cmdline-armv5te-toolchain-1.6.sh
To create generic SDK, use meta-toolchain
$ bitbake meta-toolchain
Find how to set up Qt here
I am on Ubuntu 14.04.3 platform. While I was compiling a project it asked cmake version 3.2 which is not present in my system. I compiled the latest version of cmake from source code and installed it into /usr/local/bin directory. When I attempt to compile project again, its cmake detects the cmake in /usr/bin which is lower version. Then cmake ..
process aborts with lower version error. Is there any built-in cmake variable or environment variable for setting path of the cmake?
EDIT:
I just found a cmake variable CMAKE_COMMAND that supposedly does what I want.
But when I insert CMAKE_COMMAND = /usr/local/bin/cmake line into cmakelist.txt then I go to build directory and issue /usr/local/bin/cmake ..
I get :
Expected a command name, got unquoted argument with text
I searched for it on the net but didn't find a solution.
If you have different versions of a software or library installed you may use stow to install and switch between the two. Especially if you want to install a newer version of a software that is not available in one's Linux distribution. So in case the new version is not yet stable you can still switch to the previous one. For example while building cmake 3.2 you can specify the prefix as
./configure --prefix=/usr/local/stow/cmake-3.2/
and then
cd /usr/local/stow
sudo stow cmake-3.2
and if you want to remove the links you can use the following command
sudo stow --delete cmake-3.2
Please keep in mind stow does not delete files. It only makes and deletes links.
Would it be possible to have a nightly build Rust compiler for convenience (faster build cycle, auto-update) and a dev version of Rust cloned from GitHub for experimentation purposes?
The idea is I have a binary version of Rust for my various project and a version of Rust I can hack on, without them causing havoc between each other.
If it matters, assume my OS is Ubuntu 64-bit.
The current solution is to use rustup. Once installed, you can install multiple toolchains:
rustup install nightly
rustup install stable
rustup install 1.7
If you have a local build of Rust, you can link it as a toolchain
rustup toolchain link my-development /path/to/rust/code
You can pick a default toolchain
rustup default stable
Or add an override toolchain for a specific directory on your machine only via rustup
cd /my/cool/project
rustup override set nightly
Or add an override toolchain that lives with a specific directory, like a repository, via a rust-toolchain file
cd /my/cool/project
echo "nightly" > rust-toolchain
If you want to just use a different toolchain temporarily, you can use the "plus syntax":
rustc +1.7 --help
cargo +nightly build
In other cases you can use rustup run to run any arbitrary command in a specific toolchain:
rustup run nightly any command you want here
See also:
How to execute cargo test using the nightly channel?
Sure. In the development version, use the --prefix option to ./configure, e.g. --prefix=~/opt/rust-dev, and then its installed files will be contained entirely inside that directory.
Try to configure your IDE. Though I am working on Windows computer, I think the idea is similar to Ubuntu.
First, I've installed 3 versions of Rust into:
C:\Rust\64 beta MSVC 1.9
C:\Rust\64 nightly MSVC 1.10
C:\Rust\64 stable MSVC 1.8
Then I configured my IDE (in this case, IntelliJ IDEA 2016 + Rust Plug-In) to use different versions of Rust depending on build selector.
After this I can compile my code with different Rust versions just by selecting build-config from toolbar.
You also don't need to install your development version. You could just make symlink from somewhere in your $PATH to the rustc binary that lives somewhere inside the source tree/build directory, the compiler will find its dynamically linked dependencies and it will emit binaries that know about that path too (if even dynamically linked).
Try envirius.
It allows you to create any number of environments with any version of the rust.
For the first time it will download the source code of the rust and will compile it.
And it will take some time. But second and subsequent attempts will takes under 10 seconds as it just will copy the binaries into the target environment.
For example:
➥ nv mk --rust=0.9
Creating environment: rust-0.9 ...
* installing rust==0.9 ...
* done (in 5 secs.)
➥ nv ls
Available environment(s):
rust-0.9
➥ nv on rust-0.9
Environment rust-0.9 activated.
(rust-0.9) ➥ rustc -v
rustc 0.9
Usually when dealing with rustup, you're dealing with toolchains–a single installation of the Rust compiler. There are 3 major release channels:
stable
beta
nightly
The channel can be appended with optional date and host names: channel[-date][-host].
You can install multiple toolchains using rustup:
rustup toolchain install nightly
rustup toolchain install stable-x86_64-pc-windows-msvc
Be careful when nightly is installed as any updates using rustup update will also update stable.
You can have different level of overrides:
# command level
rustc +beta <command>
cargo +beta <command>
# environment level
export RUSTUP_TOOLCHAIN=nightly-2019-05-22
# directory level
rustup override set stable
The toolchain configuration can also be version controlled using a rust-toolchain file, which contains just the toolchain name.
$ cat rust-toolchain
nightly-2019-05-22
No host name can be configured in the rust-toolchain file.
The override precedence is:
An explicit toolchain, e.g. cargo +beta
The RUSTUP_TOOLCHAIN environment variable
A directory override, ala rustup override set beta
The rust-toolchain file
The default toolchain
Reference: https://github.com/rust-lang/rustup.rs#toolchain-specification
I am currently using ubuntu 9.10 with the glibc version 2.11.1-0,
well i am doing a project, that i want to test with the another version of glibc that is 2.5-58, i wanted to know following things regarding this:
How to compile the version of 2.5-58, however keeping the previous version?
How to link the existing programs with the binaries of newer version of glibc?
I would be highly obliged if anybody can help me!!!
Thanks
If you want to manually compile another version of glibc, then I suggest you configuring (./configure script run) it with --prefix option to install not to /lib, /usr/lib but to /home/mehul/glibc2.5.58test/lib and /home/mehul/glibc2.5.58test/usr/lib
But compiling of glibc is not very easy thing, so another way is to get glibc 2.5-58 in compiled form from other linux and manually copy it to some subdirectory. Then you can override library search path of gcc and recompile your lib with libc from subdirectory.
Or you can use LD_LIBRARY_PATH to override library search path of compiled binary to use older glibc like this:
$ LD_LIBRARY_PATH=/home/mehul/glibc2.5.58test/lib /path/to/your/application
If you know that that version of libc is used in an older ditribution, you could install that distribution in a chroot/scratchbox/kvm/qemu/livecd or other such system for testing and building. Or there may be some other build farm type solution. Then you'll have an authentic system to test on that will not mess up your up to date one. It'll also be repeatable if you keep that system image.
If this isn't about a specific older release, why on earth would you want to test against a specific very old libc?