Toolchain updates#259
Merged
Merged
Conversation
The "Config" section variables are meant for package configuration. As such, they should be set when creation of the package starts, not when it is about to be finalized. Otherwise these settings could not apply for dependencies.
Each Config variable may have a default value. It is applied if the value is not present.
These abbreviations are used on Arm for the "Scalable Matrix Extensions". Ignore them as false positives.
The toolchain provides the default CFLAGS and CXXFLAGS. On the one hand,
the compiler has a default architecture and CPU model. But sometimes the
project may want to select a different architecture or CPU. This is done
by the -march= and -mcpu= flags. Providing some hooks with
CROSS_TOOLCHAIN_ARCH and CROSS_TOOLCHAIN_CPU to set these flags when the
toolchain is brought in:
depends:
- name: devel::cross-toolchain-x86_64-linux-gnu
use: [tools, environment]
forward: True
environment:
CROSS_TOOLCHAIN_ARCH: skylake
This will add "-march=skylake" to the CFLAGS and CXXFLAGS. More
importantly, this will enable us later to extract the selected features
(e.g. AVX) of the target architecture/CPUs.
Some packages need to know which features the targeted system/CPU has. This depends on the compiler settings in the first place. We now have all the information about the selected model. Based on the selected gcc and CFLAGS configuration, the available features can be extracted. They are provided as different CPU_HAS_* toolchain variables. There are different variables for the different architectures. Define the most commonly used for the moment. This schema can be extended in the future as needed.
This is available as regular tool. No need to require it on the host and neither in the sandbox.
Instead of passing it to every linker invocation, set the default hash style for symbol tables directly at binutils. This will reduce the clutter and will affect all built binaries.
When compiling for the host, the AUTOCONF_HOST variable does not need to be set. Prepare the recipes to cope with this. Traditionally, AUTOCONF_HOST was always set to the same value as AUTOCONF_BUILD but this is slightly misleading.
Setting the default C(++) toolchain tool names in default.yaml is dangerous. They are then set all the time even if not target toolchain is used. This is especially true for AUTOCONF_HOST which should better not be set at all. Otherwise we could accidentally indicate cross compilation if the target-toolchain is not used but the (old) definition is retained from default.yaml.
Even glibc apparently links some small C++ programs. Looking forward to L4Re support, a C++ compiler is even a prerequisite.
This is not a general-purpose class but an implementation detail of basement. Move it to the right namespace.
This is not a general-purpose class but an implementation detail of basement. Move it to the right namespace.
Takes a target triplet and returns either "glibc" or "uclibc".
Provide some helper functions to selectively edit the kconfig configuration. Usually, a "make oldconfig" or the like is necessary to get the final configuration values.
Unfortunately, we have to explicitly disable libsanitizer for uclibc because it does not build. The libc::libc-tgt package is now virtual because the right package needs to be selected, depending on the libc flavour.
They are not required and just bloat the system.
Sometimes special options need to be passed to gcc configure. Provide a variable for such cases.
VFPv4 support is nothing that should be assumed on generic Armv7-A architectures. Instead, set the architecture to armv7-a+fp which implies an VFPv3 by default. This brings us in line with other standard cross compilers, like on Debian.
jkloetzke
force-pushed
the
toolchain-updates
branch
from
7360c8c to
c009f29
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add support to select
-marchand-mcpufor a cross-toolchain. Based on this information, extract the target CPU feature flags for the common architectures.While at it, add RISC-V support...