I wanted to use my platform toolchain before.
but changing toolchain isn't easy for me.
I don't know external toolchain is allowed by yocto
How can I do?
Thank you so much
step:
clone poky and meta-external-toolchain
clone https://github.com/BPI-SINOVOIP/BPI-W2-bsp.git to /tmp
modify/add conf/local.conf
3.1 modify MACHINE ??= "qemux86" to MACHINE ??= "qemuarm64"
3.2 add EXTERNAL_TOOLCHAIN = "/tmp/BPI-W2-bsp/toolchains/asdk64-4.9.4-a53-EL-3.10-g2.19-a64nt-160307"
add meta-external-toolchain path to conf/bblayers.conf
run bitbake xz -e | grep CC=
I got the messages
export CC="aarch64-poky-linux-gcc -march=armv8-a+crc -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/tmp/poky/build/tmp/work/aarch64-poky-linux/xz/5.2.4-r0/recipe-sysroot"
but I want to use this gcc to build packages
/tmp/BPI-W2-bsp/toolchains/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
How can I modify it??
External Toolchain is supported in yocto. you can do this by setting value to TCMODE & EXTERNAL_TOOLCHAIN variable (Ref Yocto ref-manual). Find more information for setting external toolchain from this meta-sourcery
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 the latest CS:GO update, a valve dev commented this on the reddit post:
We are upgrading the compiler toolchain we use to build CS:GO. This
pre-release branch has CS:GO built with the new toolchain. We are
releasing it as a pre-release branch to allow for testing ahead of it
being used in the next update.
There are no functional changes expected, though the new compiler
toolchain may yield a small performance boost.
Can anyone explain what a compiler toolchain is?
A tool chain is a set of tools (chain of tools) that are used to create a programmed product (runnable/executable program etc.).
Usually toolchains are used in the embedded world for cross-compiling, which means creating a program on a host which will eventually run on a different kind of target - therefore there is a need to create it with a specific compiler, linker, debugger etc.
In order to create from scratch a compiler for the target, you need to cross-compile it with a specific toolchain - that is the compiler toolchain.
So, by using the compiler toolchain you will be able to create a compiler for your target system.
A compiler toolchain is a set of tools, supporting libraries and header files that help build a program from source to an executable that can run on a machine. To see what different tools are invoked during a compilation process pass '-v' flag. e.g., gcc -v hello.c will print the following (Note comments # are mine):
$ /usr/local/Cellar/gcc/11.2.0/bin/gcc-11 -v hello.c
# Configuration options which were used to build gcc itself.
Using built-in specs.
COLLECT_GCC=/usr/local/Cellar/gcc/11.2.0/bin/gcc-11
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/lto-wrapper
Target: x86_64-apple-darwin20
Configured with: ../configure --prefix=/usr/local/Cellar/gcc/11.2.0 --libdir=/usr/local/Cellar/gcc/11.2.0/lib/gcc/11 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran,d --program-suffix=-11 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-zstd=/usr/local/opt/zstd --with-pkgversion='Homebrew GCC 11.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-libphobos --build=x86_64-apple-darwin20 --with-system-zlib --disable-multilib --without-build-config --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Homebrew GCC 11.2.0)
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.5.0' '-asm_macosx_version_min=11.5' '-mtune=core2' '-dumpdir' 'a-'
# Compiler invocation of cc1
/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/cc1 -quiet -v -D__DYNAMIC__ hello.c -fPIC -quiet -dumpdir a- -dumpbase hello.c -dumpbase-ext .c -mmacosx-version-min=11.5.0 -mtune=core2 -version -o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//ccfvEkdl.s
GNU C17 (Homebrew GCC 11.2.0) version 11.2.0 (x86_64-apple-darwin20)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../../../../../x86_64-apple-darwin20/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/include
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/include-fixed
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks
End of search list.
GNU C17 (Homebrew GCC 11.2.0) version 11.2.0 (x86_64-apple-darwin20)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d0f2649375ab2f2193374e77e0a72e7c
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.5.0' '-mtune=core2' '-dumpdir' 'a-'
# Assembler invocation
as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=11.5 -o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//ccfvEkdl.s
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1as -triple x86_64-apple-macosx11.5.0 -filetype obj -main-file-name ccfvEkdl.s -target-cpu penryn -fdebug-compilation-dir /Users/Coolest -dwarf-debug-producer "Apple clang version 12.0.5 (clang-1205.0.22.9)" -dwarf-version=4 -mrelocation-model pic -mllvm -disable-aligned-alloc-awareness=1 -o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//ccfvEkdl.s
COMPILER_PATH=/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/:/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/
LIBRARY_PATH=/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/:/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../../
COLLECT_GCC_OPTIONS='-v' '-mmacosx-version-min=11.5.0' '-mtune=core2' '-dumpdir' 'a.'
/usr/local/Cellar/gcc/11.2.0/libexec/gcc/x86_64-apple-darwin20/11.2.0/collect2 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -dynamic -arch x86_64 -macosx_version_min 11.5.0 -weak_reference_mismatches non-weak -o a.out -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0 -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../.. /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o -lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
collect2 version 11.2.0
# linker invocation
/usr/bin/ld -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/ -dynamic -arch x86_64 -macosx_version_min 11.5.0 -weak_reference_mismatches non-weak -o a.out -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0 -L/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0/../../.. /var/folders/1n/lll3n8mj6wj975zjw804hg300000gq/T//cc2nzxXo.o -lSystem -lgcc_ext.10.5 -lgcc -lSystem -no_compact_unwind -v
#(#)PROGRAM:ld PROJECT:ld64-650.9
BUILD 00:19:30 Mar 17 2021
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11/gcc/x86_64-apple-darwin20/11.2.0
/usr/local/Cellar/gcc/11.2.0/lib/gcc/11
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
Framework search paths:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/
Note that a compiler toolchain is necessary to build executables but it is not sufficient. What is missing from the toolchain to have ‘everything’ that is needed to build executable programs is the ‘sysroot’.
Normally when we compile a program for the same machine the compiler uses the standard headers available in ‘/usr/include‘ and libraries from ‘/usr/lib‘. These paths are hardcoded in the compiler itself so we never have to think about it. However, when building a custom compiler or when cross-compiling programs we have to tell the compiler where the sysroot is by passing a flag e.g.
gcc --sysroot="/path/to/arm64/sysroot/usr" hello.c
Most often pre-packaged cross compilers come with a script/binary that has a ‘sysroot’ path embedded into it. e.g., aarch64-linux-gnu-gcc (https://packages.ubuntu.com/xenial/devel/gcc-aarch64-linux-gnu).
Alright guys, I posted a similar question and took it down because it wasn't specific enough so here I go. From the zip file of Freetype 2.6.5 I have not been able to create an Xcode project that will compile the library for iOS use, only for i386_64.
I tried the commands here but I don't get past the first commands the and I am getting this
FreeType build system -- automatic system detection
The following settings are used:
platform unix compiler cc
configuration directory ./builds/unix configuration rules
./builds/unix/unix.mk
If this does not correspond to your system or settings please remove
the file `config.mk' from this directory then read the INSTALL file
for help.
Otherwise, simply type
/Applications/Xcode.app/Contents/Developer/usr/bin/make' again to
build the library, or
/Applications/Xcode.app/Contents/Developer/usr/bin/make refdoc' to
build the API reference (this needs python >= 2.6).
cd builds/unix; \
./configure 'CFLAGS=-arch i386' /bin/sh: ./configure: No such file or directory make: *** [setup] Error 127
I also followed the instructions inside the cmakelists.txt that it comes inside the project but still nothing, I still get an xcode project for osx and not for IOS which is giving me a plethora of linking errors. Here is the instructions for your reference.
For an iOS static library, use
#
cmake -D IOS_PLATFORM=OS -G Xcode
#
or
#
cmake -D IOS_PLATFORM=SIMULATOR -G Xcode
I am not sure what else to do. Any help?
Here's an outline of the basic build process to compile the FreeType libaries for iOS:
Download the latest FreeType source code
Extract the archive and cd into the unarchived directory
Setup toolchain and export variables for the architectures desired (arm64, arm7, i386, x86_64)
Compile the source code and build the libraries
For example, the build commands for arm64 might look something like this:
$ export CC="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
$ iphoneos="7.0" # target version of iOS
$ ARCH="arm64" # architecture (arm64, arm7, i386, x86_64)
$ export CFLAGS="-arch ${ARCH} -pipe -mdynamic-no-pic -Wno-trigraphs -fpascal-strings \
-O2 -Wreturn-type -Wunused-variable -fmessage-length=0 -fvisibility=hidden \
-miphoneos-version-min=$iphoneos -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include/libxml2 \
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk"
$ export AR="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar"
$ export LDFLAGS="-arch ${ARCH} -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk \
-miphoneos-version-min=7.0"
$ ./configure --host="aarch64-apple-darwin" --enable-static=yes --enable-shared=no
$ make
$ clean
It's a bit of work to construct the commands for each arch, but
fortunately there's a build
script
— which automatically downloads, extracts, and builds the latest FreeType (2.6.5 currently).
To run the script just use the following command in Terminal:
./build_freetype.sh
The resulting iOS libraries can be found in ~/Desktop/FreeType_iOS_Release when it completes.
I'm developing an iPhone application and I'm kind of new to everything. I'm working on Mountain Lion OS X 10.8 and using xCode v4.5. I need JPEG handling capabilities in my project and I want to use the libjpeg (http://www.ijg.org/) library. I have tried a few different approaches, but being a bit naive, I'm not really sure how to begin. After downloading packages I've made usual ./configure; make and make install. Right now I have (jconfig.h, jerror.h, jmorecfg.h, jpeglib.h) under (/usr/local/include) and (libjpeg.a, libjpeg.la) under (/usr/local/lib) but I have no idea how to link/use this in my xCode project.
Can anyone link me to a tutorial or give me a push in the right direction?
If anyone successfully installed and used jpeg library please help..
This is a bit of a pain, because you will need to compile LibJPEG for two architectures: ARM, for iOS, and x86, for the simulator.
Your best bet is to use NSImage or CGImage. There already is a JPEG library on iOS, supplied with the system, so you don't need to use LibJPEG.
An alternative is to put the LibJPEG sources directly into your project (including the *.c files). This way, they will be built correctly for different architectures (simulation and deployment).
You could also just build for ARM, and then forget about running the simulator.
Or you could build LibJPEG as a fat binary by compiling it twice and combining the resulting library (libjpeg.a) from each compilation with libtool.
libtool -static path/to/arm/libjpeg.a path/to/x86/libjpeg.a -o libjpeg.a
You can see why the recommendation is to use NSImage or CGImage. Better to use a library that is already installed rather than try to build and install a new one.
How to make a fat static library
Since it sounds like you want to do things the hard way, here is an example of how to build a fat static library for i386 and ppc architectures. This was done on a PowerPC OS X box, you will have to adjust if you want to compile for ARM and i386.
Note that you have to specify --host and --build for cross-compiling. The values below are correct for my computer, but I am certain that they are wrong for your computer.
$ cd jpeg-8d
$ mkdir build-ppc build-i386
$ cd build-ppc
$ ../configure CFLAGS='-arch ppc -O2 -g' LDFLAGS='-arch ppc' \
--enable-static --disable-shared
$ make -j2
$ cd ../build-i386
$ ../configure CFLAGS='-arch i386 -O2 -g' LDFLAGS='-arch i386' \
--enable-static --disable-shared \
--build=powerpc-apple-darwin9.8.0 --host=i386-apple-darwin9.8.0
$ make -j2
$ cd ..
$ file build-ppc/.libs/libjpeg.a
build-ppc/.libs/libjpeg.a: current ar archive random library
$ file build-i386/.libs/libjpeg.a
build-i386/.libs/libjpeg.a: current ar archive random library
$ libtool -static build-*/.libs/libjpeg.a -o libjpeg.a
$ file libjpeg.a
libjpeg.a: Mach-O universal binary with 2 architectures
libjpeg.a (for architecture i386): current ar archive random library
libjpeg.a (for architecture ppc): current ar archive random library
For running testcases etc. I would like to compile parts of our buildroot environment for the Host system (/usr/bin/gcc etc.).
I tried specifying an external_toolchain in /usr but this fails. Has anyone managed to do something like this?
The buildroot manual says this is unsupported because they can not import it into a rootfs. But for testcases a rootfs is not necessary.
Yeah, unfortunately, it is not possible to do this. To be useful for Buildroot, a toolchain has to be a "pure" toolchain, i.e containing only the C library binaries and headers. You /usr is cluttered with gazillions of libraries from your host machine, and since Buildroot makes a full copy of the toolchain sysroot (which in your case, would be /usr), it would copy many, many things.
So definitely, it is not something that we support, and we don't intend to support this. You can also decide to build your programs with a x86 or x86_64 cross-compiler, have Buildroot generate a minimal Linux system, and chroot into it directly on your development PC.
The current documentation also seems to explain that this is not possible https://github.com/buildroot/buildroot/blob/2018.08/docs/manual/configure.txt#L198
We also do not support using the distribution toolchain (i.e. the
gcc/binutils/C library installed by your distribution) as the
toolchain to build software for the target. This is because your
distribution toolchain is not a "pure" toolchain (i.e. only with the
C/C++ library), so we cannot import it properly into the Buildroot
build environment. So even if you are building a system for a x86 or
x86_64 target, you have to generate a cross-compilation toolchain with
Buildroot or crosstool-NG.
Furthermore, current Buildroot seems to check if your toolchain path seems to be a global toolchain, and bails out automatically if it is https://github.com/buildroot/buildroot/blob/2018.08/toolchain/helpers.mk#L395
with_sysroot=`$${__CROSS_CC} -v 2>&1 |sed -r -e '/.* --with-sysroot=([^[:space:]]+)[[:space:]].*/!d; s//\1/'`; \
if test "$${with_sysroot}" = "/" ; then \
echo "Distribution toolchains are unsuitable for use by Buildroot," ; \
echo "as they were configured in a way that makes them non-relocatable,"; \
echo "and contain a lot of pre-built libraries that would conflict with"; \
echo "the ones Buildroot wants to build."; \
exit 1; \
fi; \