What is a compiler toolchain? - toolchain

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).

Related

Scipy build fail on MacOS because LLVM producer != reader

I'm trying to build Scipy from source. However, a linking step...
/usr/bin/clang -bundle -undefined dynamic_lookup -L/Users/gwg/miniconda3/envs/scipy-dev/lib -arch x86_64 -L/Users/gwg/miniconda3/envs/scipy-dev/lib -arch x86_64 -L/usr/local/opt/libomp/lib -lomp -I/usr/local/opt/libomp/include -Xpreprocessor -fopenmp -arch x86_64 build/temp.macosx-10.9-x86_64-3.7/scipy/spatial/src/distance_wrap.o -L/Users/gwg/miniconda3/envs/scipy-dev/lib/python3.7/site-packages/numpy/core/lib -Lbuild/temp.macosx-10.9-x86_64-3.7 -lnpymath -o build/lib.macosx-10.9-x86_64-3.7/scipy/spatial/_distance_wrap.cpython-37m-darwin.so
...fails, and I get the following error:
ld: in /Users/gwg/miniconda3/envs/scipy-dev/lib/python3.7/site-packages/numpy/core/lib/libnpymath.a(npy_math.o), could not parse object file /Users/gwg/miniconda3/envs/scipy-dev/lib/python3.7/site-packages/numpy/core/lib/libnpymath.a(npy_math.o): 'Unknown attribute kind (61) (Producer: 'LLVM10.0.0' Reader: 'LLVM APPLE_1_1000.10.44.4_0')', using libLTO version 'LLVM version 10.0.0, (clang-1000.10.44.4)' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I suspect it is due to the Producer: 'LLVM10.0.0' Reader: 'LLVM APPLE_1_1000.10.44.4_0' mismatch. But I don't know how to investigate this error.
Some details:
MacOS: High Sierra, 10.13.6
gcc --version:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
clang --version:
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I had the same issue. The suggestions here to use the conda compilers resolved the issue for me:
conda create -n scipy-dev
conda activate scipy-dev
conda config --env --add channels conda-forge
conda install numpy cython pybind11 pytest compilers openblas
python setup.py develop
It seems you're using different clang (judging from the paths like /usr/local/opt/libomp/lib). Likely the one provided by conda. In order to perform build with LTO you need to use the compatible toolchain (e.g. build everything with Apple-provided toolchain or with conda-provided one).

Compiling Freetype 2.6.5 Xcode for IOS

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.

why didn't my g++ and gcc version get upgraded?

I am on a Mac. I updated my OSx to Yosemite. I updated my xcode to version 6. I downloaded the command line tools.
And still, whenever I type in g++ --version, I get:
# g++ --version
couldn't understand kern.osversion `14.1.0'
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
meaning, I am still using the old version of g++ and gcc.
Why wasn't it upgraded? I am interested in using c++0x in Eclipse, and for that I need a newer g++/gcc compiler.
EDIT: following the comment below, I have two questions:
Why
$ clang --version
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
do I still seem to have an old version of clang?
Why didn't the installation of xcode and the command-line tools create the proper links to clang?
It looks like you maybe have an old version of xcode also installed.
From the command line you can switch to the proper one with
xcode-select --switch <path>
You should see something like this
$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
$ clang --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
I had a similar problem installing ios-deploy after upgrading to yosemite. i was getting the same
couldn't understand kern.osversion `14.1.0'
for gcc. I ultimately solved it by:
cd /opt/local/bin/
sudo rm gcc
sudo ln -s /Applications/Xcode.app/Contents/Developer/usr/bin/gcc gcc
This correctly pointed gcc to the the version provided by Xcode 6.1.

buildrpm fails when cross building C++ for 32-bit ARM (from x86-64)

I successfully compiled C++ code for a Raspberry Pi (ARM architecture).
Such binaries have a file command return the following :
usr/local/company/product/this: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=9fe73c254b317e239758e4445d12b8441a3cb13e, not stripped
I now wish to generate RPM packages (not .deb packages, real .RPM packages!).
I've tried many --target and spec's file buildarch combinations without much success.
Tried armv7l, arm-linux-gnueabihf, arm-linux ...
Same result is returned by rpmbuild :
Building target platforms: arm-unknown-linux
Building for target arm-unknown-linux
error: No compatible architectures found for build
I'm compiling from an x86_64 Ubuntu. The destination architecture is arm-linux-gnueabihf.
I call rpmbuild as follow :
rpmbuild -bb --target armv7l myfile.spec
On my RHEL 7 computer, the /usr/lib/rpm/rpmrc includes several ARM variants:
armv3l, armv4b, armv4l, armv4tl, armv5tel, armv5tejl, armv6l, armv7l, armv7hl, armv7hnl. I guess your file will have a similar selection, and thus include the armv7l option you selected.
I found that for cross-packaging, running rpmbuild --target _target_ was not enough. I also had to use a setarch _target_ wrapper around the build command.
You may need to add your arm architecture (displayed by uname -m) to /usr/lib/rpm/rpmrc configuration.
GOARCH=amd64 or arm64
used the command:
rpmbuild ... --define="GOARCH ${GOARCH}"
spec file should include this content
%if %{GOARCH} == "amd64"
BuildArch: x86_64
%endif
%if %{GOARCH} == "arm64"
BuildArch: aarch64
%endif

Windows + Eclipse + ARM-GCC

I would like to use eclipse IDE for my development with Tiva (LM4F) processor. I did this tutorial. Kernel hacks tutorial.
I use Win 8.1 x64 + eclipse + ARM-GCC and I would like to program a LM4F MCU.
I sat up everything, compiler path, the driverlib path. But It can't find the correct dependencies
Invoking: Cross GCC Compiler
arm-none-eabi-gcc -DPART_LM4F120H5QR -DTARGET_IS_BLIZZARD_RA1 -DARM_MATH_CM4 -I../.. /../stellarisware/ -I../../../stellarisware/utils -I../../../stellarisware/driverlib -I../../../stellarisware/inc/ -O0 -g3 -Wall -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -ffunction-sections -fdata-sections -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"
c:/gnu_gcc_arm/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7e-m/softfp\libg.a(lib_a-exit.o): In function 'exit':
exit.c:(.text.exit+0x16): undefined reference to '_exit'
C:\Users\MTYS~1\AppData\Local\Temp\ccECjb0N.o: In function 'Init_Adc':
C:\eclipse_workspace\proba\Debug/../main.c:20: undefined reference to 'SysCtlPeripheralEnable'
And all of driver functions gave me error.
And my path is (windows path: C:\stellarisware\, the project folder is C:\eclipse_workspace\try):
../../../stellarisware/
../../../stellarisware/utils
../../../stellarisware/driverlib
../../../stellarisware/inc/
I tried different methods (use cygwin path, or absolute windows path), the code can be compiled successfully with IAR. What should I do?