Run samples through upgrade and fix accumulated breakages:
*-centos6-*: After 2.12.2 retirement, the samples selected most recent
glibc (2.34) which also forced kernels 3.2+. Revert to 2.12.1 and
2.6.32.71, respectively. Interestingly, 2.12.1 was marked as being used
in CentOS6, but the samples selected 2.12.2. Anyway, CentOS6 is EOL now
and glibc 2.12 is going to be marked obsolete, and retired soon.
arc-*: Make TARGET_VENDOR match the sample's name; otherwise `ct-ng
saveconfig` places the config file into a different location.
Fix 'savedefconfig' which was not saving the configuration file version
(CT_VCHECK was set to 'load' after CT_LoadConfig call).
Signed-off-by: Alexey Neyman <stilor@att.net>
From GCC's standpoint ARC's multilib items are defined by "mcpu" values
which we have quite a few and for all of them might be built optimized
cross-toolchain.
From Glibc's standpoint multilib is just multi-ABI [1] and so very limited
versions are supposed to co-exist (e.g. arc700 & archs).
Here we force Glibc to install libraries in GCC's multilib folder to create
a universal cross-toolchain that has libs optimized for multiple CPU types.
But note we only need to mess with installation paths in case of real
multilib, otherwise we keep default "lib/" paths so that GCC finds default
(the one and only) libs where it expects them to be.
Also here we add a sample which allows to build universal Glibc Linux
toolchain for ARC.
[1] https://sourceware.org/ml/libc-alpha/2019-06/msg00018.html
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
