I'm just starting to learn Yocto 1.8.
The bitbake meta-toolchain ran fine as described in the documentation and generated the appropriate installation script. However, bitbake picked a version of GCC that I don't want.
What is the recommended way to tell bitbake which version of GCC to pick for the bitbake meta-toolchain build?
Just to keep the record complete.
The exact GCC version is specified in the machine/.conf file as:
# This version is Yocto-branch dependent
PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} ?= "5.2%"
Related
I am attempting to build a Windows toolchain from Yocto (running on Linux) so that we can use a different build system to build applications for our embedded device. Yocto is running on Ubuntu 18.04.
I looked at Can't generate SDK for Windows with Yocto and How do I generate a toolchain for Windows using Yocto? and have added meta-mingw to my Yocto work directory; I am running Yocto Zeus, so I cloned it with command git clone git://git.yoctoproject.org/meta-mingw -b zeus and added it to my bblayers.conf file. I also added SDK_ARCH = "x86_64" to my local.conf
I am building the toolchain by running bitbake meta-toolchain. I am trying to build a set of 64 bit binaries (we have had out of memory issues with our existing 32-bit Linaro toolchain).
I am seeing the install script as you would expect in /home/gen-ccm-root/workdir/tools/poky/build-dev/tmp/deploy/sdk but all the binaries it built were Linux ELF files. What step am I missing? I didn't see how to do this in the Yocto SDK manual (https://www.yoctoproject.org/docs/3.0/sdk-manual/sdk-manual.html) Is there a different document I should be looking at?
A couple of other things I have tried:
Changing SDK_ARCH in my local.conf to SDK_ARCH = "x86_64-mingw64" which didn't rebuild anything (after I built the Linux toolchain above)
Adding #SDKMACHINE ?= "x86_64-mingw64" to the local.conf
I tried mingw32 as well since that is what is in the layer conf.
meta-toolchain doesn't appear to work anymore.
In the end, I added meta-mingw to my bblayers.conf and the following to my local.conf:
SDKMACHINE = "x86_64-mingw32"
SDK_ARCHIVE_TYPE = "zip"
And, after building building my project, used the following to build the SDK: bitbake mi-dev -c populate_sdk where mi-dev is my build.
From this link:
http://embeddedguruji.blogspot.com/2018/11/oe-depends-dot-in-yocto.html
It says
To use oe-depends-dot utility you need to first generate
recipe-depends.dot file
When i run in zeus branch of poky, i don't get recipe-depends.dot file
$ bitbake -g core-image-minimal
It only creates pn-buildlist, task-depends.dot
Can we pass 'task-depends.dot' to oe-depends-dot tool?
Generation of recipe-depends.dot has been removed in Bitbake version 1.43.2 (and newer), see commit 4c484cc01e3eee7ab2ab0359fd680b4dbd31dc30. This affects Yocto versions 3.0 and up.
It appears that the documentation had not been updated right away. However, the latest Bitbake documentation does not include references to the file anymore.
We have a Solaris 11 system with gcc 7.3, we need to install the Ada package. On Linux gcc 7 came with the Ada/GNAT as part of the gcc install:
apt install gcc
I visited AdaCore looks like Solaris (SPARC) is not longer on the list. I need to use Ada95 and we want the same compiler on both Linux and Solaris in any case.
pkg install gcc
Only installed various C++ commands and Fortran.
pkg install gcc-ada
And variants like gcc7ada, found nothing to install.
If must, we can rebuild the Ada component of GCC 7, however I haven't found a clear cood-book style "How To ..."for that (yet).
Hopefully you can point me to these items in order of preference to help us get back-on-track.
Solaris 11 gcc-ada package for gcc7/Solaris 11 spark, and the package repository.
An 'alternative' package repository were I can retrieve the GCC Ada tooling.
Pre-build GCC 7 Ada module that we can copy to the right places.
Ready-rolled Build Ada/GNAT project for Solaris and how to download and get start building.
Instructions to download and build gcc-ada with gcc 7 on Solaris (or Unix).
From th epast few days searching about on Gnu Compiler Collection, Oracle, the package manager searches, google and so forth ... It really seems like there's next to no support for CGG Ada on Solaris these days.
I very interested in other solutions beyond that list. For instance, has anyone cross-compiled from Linux to Solaris? Would that work with GDB on the Solaris machine anyway?
Looking forward to your suggestions.
I've successfully built gcc 7.50 (x86_64 native with i386 cross-compiler) with GNAT on OpenIndiana (Hipster 2020/10) using the following procedure.
Download the bootstrap compiler from Dragonlace at http://downloads.dragonlace.net/src/ada-bootstrap.x86_64.solaris.511.tar.bz2
Get the illumos gcc 7.5.0 source from https://github.com/illumos/gcc/tree/il-7_5_0
Put the bootstrap compiler's bin directory at the front of $PATH, replace /usr/bin/gcc /usr/bin/cpp /usr/bin/g++ with symlinks to their counterparts in the bootstrap compiler directory (see note below re g++ and c++)
Make sure you've got gnu-binutils and gmake; then run contrib/download_prerequisites
Configure with
--enable-languages='c ada c++' --build=x86_64-aux-solaris2.11 --enable-threads=posix --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-nls --disable-shared --disable-lto --disable-libstdcxx-pch --enable-multilib --with-gnu-as --with-as=/usr/bin/gas --without-gnu-ld --with-ld=/usr/bin/ld
gmake and then gmake install
NOTES:
This setup should be close enough to Solaris 11 to work. If it doesn't, try using the regular gcc 7.5.0 release rather than the illumos-modified branch.
If you get stuck at a linking stage, try using a gcc ld, but you should definitely try to use the Solaris ld first. The gnu as (gas) makes the build go much more smoothly. I didn't have any problems, but if you get stuck at the end of stage 1 or the beginning of stage 2, try setting $CONFIG_SHELL=/usr/bin/ksh -- I think it has been fixed, but at least with older gcc releases one needed to specify ksh because the built-in sh had some non-POSIX peculiarities that didn't work with some of the components' makefiles
I couldn't get one of the support libs for gnat to compile easily without building gcc c++ and using g++ with a full bootstrap. You might be able to figure it out, but the path of least resistance is likely to build gcc c++ and put the g++ symlink in /usr/bin, which is where the makefile wanted to find it.
Please note that I don't know much about Solaris, but a quick search on Google gave me the website OpenCSW. This website provides the packages gcc4ada and gcc5ada.
It appears that gcc5ada is build using a makefile (as found here, in particular notice line 424). A similar makefile exists for gcc7ada (as found here, in particular notice line 426). However, while it seems that the package "gcc7ada" can be created with the latter makefile, it is not published on the OpenCSW.org website (website is no longer updated?).
You could try to install gcc5ada first and then use this old GCC/GNAT compiler as a bootstrapper for compiling the required version (using the GCC 7 makefile).
There are some posts about this for the older releases of MATLAB, but they don't seem to work for R2016a.
I'm trying to install MatConvNet on Ubuntu 16.04. When I run the vl_compilenn command as described here, it gives me a warning as follows:
Building with 'gcc'.
Warning: You are using gcc version '5.4.1'. The version of gcc is not supported.
The version currently supported with MEX is '4.7.x'. For a list of currently supported
compilers see: http://www.mathworks.com/support/compilers/current_release.
I have already installed gcc-4.7 and g++-4.7 using apt-get install gcc-4.7 g++-4.7. How can I force MATLAB to use these versions and not the default ones?
Few hints, not a complete tutorial how to do it.
Probably the simplest would be to edit the MATLAB's Mex XML configuration file:
mex -setup C
cc = mex.getCompilerConfigurations('C', 'Selected')
edit(cc.MexOpt)
The mex setup usually creates a copy in your home folder (~/.matlab/<version>/mex_C_glnca64.xml), so you should be able to edit it without root.
There you probably need to change the section:
<GCC>
<cmdReturns name="which gcc" />
</GCC>
which I guess searches for the location of the gcc command to your gcc version and assigns it to the $GCC variable. Plus you can change the version name in the header.
Additionally you need to do the same for the C++ language.
This works with R2016b:
Install the required GCC version with apt install (gcc-4.9 and g++-4.9 in my case).
Create a bin folder in your home, i.e. ~/bin.
Create the following links with ln:
ln -s /usr/bin/gcc-4.9 ~/bin/gcc
ln -s /usr/bin/g++-4.9 ~/bin/g++
If using CUDA, create a file called nvcc in the ~/bin folder, with the following contents (don't forget to make it executable: chmod +x ~/bin/nvcc):
Contents:
#!/bin/sh
exec /usr/lib/nvidia-cuda-toolkit/bin/nvcc -ccbin gcc-4.9 "$#"
If necessary replace /usr/lib/nvidia-cuda-toolkit/bin/nvcc with the correct location of the nvcc binary.
Open MATLAB and follow the instructions for compiling MatConvNet.
I have problems building a portable executable with rust.
Running an executable simply built with cargo build on Ubuntu fails with
./test: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./test)
Building with rustc ... -C link-args=-static fails to link correctly (output of ld ./test):
ld: error in ./test(.eh_frame); no .eh_frame_hdr table will be created.
Is there a way around this except building on an older system with an old glibc version?
Glibc is not linked statically (much as we might have liked to, it goes out of its way to prevent this). As a result, the system libraries (libstd and such) are always dependent on the glibc version on which they were built. This is why the buildbots in the linux cluster mozilla uses are/were old versions of centos.
See https://github.com/rust-lang/rust/issues/9545 and https://github.com/rust-lang/rust/issues/7283
Unfortunately at this time I believe there is no workaround aside from making sure you build on a system with an older glibc than you're going to deploy to.
To avoid GLIBC errors, you can compile your own version of Rust against a static alternative libc, musl.
Get the latest stable release of musl and build it with option --disable-shared:
$ mkdir musldist
$ PREFIX=$(pwd)/musldist
$ ./configure --disable-shared --prefix=$PREFIX
then build Rust against musl:
$ ./configure --target=x86_64-unknown-linux-musl --musl-root=$PREFIX --prefix=$PREFIX
then build your project
$ echo 'fn main() { println!("Hello, world!"); }' > main.rs
$ rustc --target=x86_64-unknown-linux-musl main.rs
$ ldd main
not a dynamic executable
For more information, look at the advanced linking section of the documentation.
As reported in the original documentation:
However, you may need to recompile your native libraries against musl
before they can be linked against.
You can also use rustup.
Remove old Rust installed by rustup.sh
$ sudo /usr/local/lib/rustlib/uninstall.sh # only if you have
$ rm $HOME/.rustup
Install rustup
$ curl https://sh.rustup.rs -sSf | sh
$ rustup default nightly #just for ubuntu 14.04 (stable Rust 1.11.0 has linking issue)
$ rustup target add x86_64-unknown-linux-musl
$ export PATH=$HOME/.cargo/bin:$PATH
$ cargo new --bin hello && cd hello
$ cargo run --target=x86_64-unknown-linux-musl
$ ldd target/x86_64-unknown-linux-musl/debug/hello
not a dynamic executable