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.
Related
We are generating Yocto SDK using the following command: bitbake -c populate_sdk <image-name>
Yocto Branch : Dunfell
We don't see header files getting included in the SDK, for example we have libmodbus part of IMAGE_INSTALL, we don't see modbus.h file in SDK which is present in libmodbus-dev package
Could you execute the command below so we can verify your setup:
bitbake -e <image-name> | grep SDKIMAGE_FEATURES
Development packages are automatically included into SDK when they are installed into the image when SDKIMAGE_FEATURES variable defines it
SDKIMAGE_FEATURES = "dev-pkgs staticdev-pkgs"
https://www.yoctoproject.org/docs/3.1/mega-manual/mega-manual.html#var-SDKIMAGE_FEATURES
First step I cloned the pulseaudio source from git [ git clone https://gitlab.freedesktop.org/pulseaudio/pulseaudio.git ]. Secondly went inside the pulseaudio directory and executed meson build command in order to move to the build directory as stated in README file. But i'm getting this error while excecuting this meson build command.
androidbuild#androidbuild-PC:~/pulse/pulseaudio$ (master) meson build
The Meson build system
Version: 0.45.1
Source dir: /home/androidbuild/pulse/pulseaudio
Build dir: /home/androidbuild/pulse/pulseaudio/build
Build type: native build
meson.build:345:61: ERROR: Expecting eol got eol_cont.
if cc.has_header_symbol('sys/syscall.h', 'SYS_memfd_create') \
^
A full log can be found at /home/androidbuild/pulse/pulseaudio/build/meson-logs/meson-log.txt
Likely Meson began silently supporting using \ escaped newlines sometime after meson 0.45.1 (the version you have installed). Looking at the gitlab, pulse audio requires meson >= 0.50 anyway, so this should have failed already. Since you have 0.45 I'm assuming your on an LTS of some kind (since 0.58 is the latest release), I think Ubuntu 20.04 had 0.45?.
This issue will likely be resolved by updating to a newer meson. You can use pip for this, pip install --user meson, or you can probably use a backport repo for your distro (Debian and Ubuntu both provide these in easy to use forms, but all LTS distros have them as some of the dependencies they need will rely on newer build tools)
Ubuntu 18.04 ARM64
I have download and built vscode and this appears to be working.
I can see the extension market place and install extensions. The C/C++ IntelliSense, debugging, and code browsing install but gets a dependency install failure sometimes:
Updating C/C++ dependencies...
Downloading package 'Mono Framework Assemblies' (5368 KB) Done!
Installing package 'Mono Framework Assemblies'
Failed at stage: installPackages
Error: end of central directory record signature not found
It seems to succeed on the second attempt but I'm not convinced.
So I have cloned vscode-cpptools and would like to built it myself but I'm not sure what dependencies it has or how to build it correctly.
Any tips appreciated!
So following the build and debug guide at:
$ git clone -b release https://github.com/Microsoft/vscode-cpptools
$ cd vscode-cpptools/Extension
$ npm install ! should install all dependencies but it forgets gulp
$ npm install gulp ! Manually install. I wonder what else it forgets
$ vsce package ! Should trigger the build and make the vsix package.
So the package is created and when I try and install it via the vscode extensions I get
Unable to start the C/C++ language server. IntelliSense features will be disabled. Error: Missing binary at ~/.vscode-oss-dev/extensions/ms-vscode.cpptools-0.22.1/bin/Microsoft.VSCode.CPP.Extension.linux.
Me thinks there are a lot of other dependencies that are missing!!!
Looking in the Extension bin folder and two important binaries are missing:
Microsoft.VSCode.CPP.Extension.linux
Microsoft.VSCode.CPP.IntelliSense.Msvc.linux
I also tried this on Intel Ubuntu 18.04 and while the Intel build appeared to do a whole lot more it also fails to build the binaries.
Found the answer in here : github.com/Microsoft/vscode-cpptools/issues/429 which indicates there is no support for Aaarch64 Arm64 at this point in time.
I am working on building and installing tensorflow on my institution's cluster computer, which is running CentOS 6.5.
Obviously, the first step is building and installing bazel. The build works just fine, but when I try to run the bazel binary, I get the following error:
Error: unexpected result from F_SETLK: Function not implemented
gcc version is 4.7.2
java version is jdk1.8.0_65
edit: I have also tried compiling gcc 4.9.4 and building with this version, and I have tried building both the latest dist of bazel, and the 0.3.1 from the git repo. All variants get the same error.
This happens if the filesystem where Bazel tries to install itself (unpack its embedded tools) doesn't support locking.
Workaround (until the relevant issue is resolved) is to specify a path on a local, writable (and file-lockable) filesystem for --output_user_root, for example:
bazel --output_user_root=/usr/local/$USER/bazelout build <targets>
I was trying to build only gcc using yocto. I tried with "bitbake-layers show-recipes" it was showing multiple recipes for gcc, similarly for bitbake -s.
#bitbake-layers show-recipes
gcc:
meta 4.8.2
gcc-cross:
meta 4.8.2
gcc-cross-canadian-arm:
meta 4.8.2
gcc-cross-initial:
meta 4.8.2
gcc-crosssdk:
meta 4.8.2
gcc-crosssdk-initial:
meta 4.8.2
gcc-runtime:
meta 4.8.2
gccmakedep:
meta 1:1.0.2
#bitbake -s
gcc :4.8.2-r0
gcc-cross :4.8.2-r0
gcc-cross-canadian-arm :4.8.2-r0
gcc-cross-initial :4.8.2-r0
gcc-crosssdk :4.8.2-r0
gcc-crosssdk-initial :4.8.2-r0
gcc-runtime :4.8.2-r0
gccmakedep 1:1.0.2-r3
Please guide me to understand why there are multiple recipes related to gcc and which one I have to build.
In yocto, is there one to one match for recipe and package. i.e for creating each package there is a corresponding only one recipe?
To explain each one in turn:
gcc is the recipe for gcc that runs on the target machine itself.
gcc-cross is the cross-compiler that the build system uses. If you build any recipe for the target that needs to be compiled with gcc, this is what will be used to compile that.
gcc-cross-canadian- is the final relocatable cross-compiler for the SDK, in this case for the ARM architecture.
gcc-crosssdk is an intermediate step in producing gcc-cross-canadian.
the *-initial are the initial versions of the compiler required to bootstrap the toolchain separately for the standard cross-compiler and for the SDK.
gcc-runtime builds the runtime components that come as part of gcc (e.g. libstdc++).
gccmakedep isn't really part of gcc itself, it's a script that comes as part of the X11 utilities that some projects need to determine dependencies for each source file.
When you say "you only need to build gcc", it's not entirely clear what you mean, but I suspect it's either gcc for the target (in which case it's "gcc", though I suspect you'll probably need more than that - packagegroup-core-buildessential may be what you want) or you want a cross-compiler you can install separately in which case you probably ought to bitbake meta-toolchain or bitbake -c populate_sdk imagename. That'll contain more than just gcc but it's likely gcc alone isn't going to be enough anyway.
GCC is a huge project. Maybe this recipe could help you understand GCC and Yocto a little bit better. The following information is some information paraphrase from "Embedded Linux Projects Using Yocto Project Cookbook" by Alex Gonzalez
GNU toolchain contains the following components:
Assembler (GNU as): part of the binutils package
Linker (GNU Id):
part of the binutils package
Compiler (GNU gcc): support for C, C++,
Java, Ada, Fortran, and Objective C
Debugger (GNU gdb): GNU debugger
Binary file tools (objdump, nm, objcopy, readelf, strip, and so on):
these are part of the binutils package
These components are enough to build bare metal applications
bootloaders like u-boot, Linux Kernel because they do not need C
library and they implement C library functions they need.
POSIX-compliant C library is needed for LInux user space applications.
glibc is the default C library used in the Yocto Project.
On Embedded Systems, we need a cross-compilation toolchain. We build
in a host computer but run the result binarines on the target which is
usually different architecture. There are several types of toolchains
based on build machine, target machine.
The most common combinations are:
Native: An example of this is an x86 machine running a toolchain that >has also been built on an x86 machine
producing binaries to run on an x86 machine. This is common in desktop
computers.
Cross-compilation: This is the most common on embedded
systems; for example, an x86 machine running a toolchain that has also
been built on an x86 machine but producing binaries to run on a
different architecture, like ARM.
Cross-native: This is typically the
toolchain running on targets. An example of this is where a toolchain
has been built on an x86 machine but runs on ARM and produces
Canadian: Rarely seen, this is where the build, host, and target
machines are all different.