This commit adds support for the following Oracle products, in order
to target Oracle Linux 7.9:
Binutils 2.27-44.base.0.400
GCC 4.8.5-44.0.5
glibc 2.17-317.0.3
UEK5/u4 4.14.35-2025.400.8
Sample configuration files are provides for the following triplets:
arm-ol7u9-linux-gnueabi
arm-ol7u9-linux-gnueabihf
Signed-off-by: Egeyar Bagcioglu <egeyar.bagcioglu@oracle.com>
Signed-off-by: Jose E. Marchesi <jose.marchesi@oracle.com>
This adds support for using picolibc instead of newlib on embedded
systems.
Signed-off-by: Keith Packard <keithp@keithp.com>
v2:
Add check for meson and ninja
Sync option default values with current picolibc defaults
Remove xtensa sys header file install as those aren't in picolibc
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>
G+ is now defunct, update the reporter_url to bootlin as both Thomas and I
are working there.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
We've had very solid support for C++ for quite a while now in RISC-V
land, at least in our Linux targets. This patch set enables C++ support
by default, which I assume most users will want.
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
- Pin sparc-leon-linux-gnu to GCC6, again.
- Remove "brokenness" explanation from moxie-elf comment (was only
applicable to stage-2 compiler, not final).
Signed-off-by: Alexey Neyman <stilor@att.net>
Slightly rework config version detector to catch the case where neither
CONFIG_VERSION/CONFIG_VERSION_CURRENT is defined in the config file.
Add olddefconfig and use it after the upgrade.
Signed-off-by: Alexey Neyman <stilor@att.net>
... while making use of the new tunables.
Also, unmark the moxie-elf as broken: the ld scripts installed by newlib
can be found by the compiler and can link the binaries. Why the default
script is broken is not ct-ng's problem...
Signed-off-by: Alexey Neyman <stilor@att.net>
This required some rework of the libc selection, as moxiebox is a layer on
top of another libc - newlib.
Also, moxiebox'es host VM (`sandbox`) needs a libcrypto on the host. We will
not have it if we're cross-compiling a canadian cross. Fortunately, all moxiebox
needs from libcrypto is SHA256, and it already includes a standalone implementation
of SHA256 in its runtime. Provide a little wrapper that allows moxiebox use
that implementation for the host binary, too.
Also, automate collecting/printing the list of all packages in a given category
(e.g. LIBC or COMP_TOOLS), generate a list of all Kconfig symbols for a given
category.
Signed-off-by: Alexey Neyman <stilor@att.net>
This sample works well for building the open-source first stage
bootloader for the SiFive U540 device (and similar):
https://github.com/sifive/freedom-u540-c000-bootloader
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
This sample works well for the SiFive U540 device (and similar).
Thanks to Jim Wilson <jimw@sifive.com> for his review, discovering
several bugs (now fixed).
Cc: Jim Wilson <jimw@sifive.com>
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
There's no point in keeping samples which are in its essense
just a sub-set of multilib toolchain.
But still we'd like to cover quite unusual but really existing
case - ARC750, i.e. ARC700 with MMU but without so-called
atomic instructions (LLOCK/SCOND). To support this HW variation
we need:
1) Compile all target binaries without "-matomics" or even
better "-mno-atomics" so that's even future-proof
(as we may decide to enable "-matomics" by default for Linux
targets which is a recommented setup).
2) Configure libc such that it uses Linux-kernel-assisted implementation
of atomic operation via "arc_usr_cmpxchg" syscall,
see https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=b985fa069187e4c5a7ee84213d9fbead2f219ce5
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
- Glibc configure args and tuple need adjustment on SuperH
- Only allow "both endian" and "with CPU" for unspecified arch
variant. May reconsider endianness (was breaking things before
adjusting glibc tuple)
- Retire non-multilib sample, it should be a subset of the
multilib one now.
Signed-off-by: Alexey Neyman <stilor@att.net>
1. On SuperH, configuring GCC with explicit variant of the CPU
(like "sh4") limits the default set of multilibs to just that CPU
and requires --with-multilib-list to change. Allow for "unspecified"
variant, so that we can defer to GCC to determine the list.
2. Support toolchains with both endiannesses at the same time.
3. Add a SuperH/newlib sample
4. Add more flags processing for uClibc
Signed-off-by: Alexey Neyman <stilor@att.net>
E.g., only include minor/major of the Linux kernel into the kconfig
symbol. In the future, to be defined by all packages, but for now
matches the current versioning in the packages.
Signed-off-by: Alexey Neyman <stilor@att.net>
Must have eabi suffix for GCC to accept it. Also:
- We only have one glibc now, no need to account for eglibc.
- Rename aarch64 samples, eabi suffix does not apply to them
(and ct-ng saveconfig was saving them into a different directory).
Fixes#772.
Signed-off-by: Alexey Neyman <stilor@att.net>
The line CT_GETTEXT=y is remains from canadian sample. This cross
sample does not need it.
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
- Update .gitignore, do not place .gitignore into directories installed
in bulk
- Remove executable permissions and shebangs from the scripts that are
supposed to be invoked only via ct-ng frontent; prepend them with $(bash).
Despite what showSamples.sh said, it already has some bashisms.
- Remove --with autotools-dev and override dh_update_autotools_config
to avoid having config.{sub,guess} clobbered with older versions
- Install bash completion where Debian (now) expects it
- Update man page to use .\" as the comment delimiter, instead of
undefined macro (."); also, minor text edits.
- Install kconfig.mk without execute permission.
- Remove shell wrappers from 170-localedef-fix-trampoline.patch, we
do not use that for applying patches
- Revoke execute permissions on 210-expat.sh
- Get flags from dpkg-buildflags if available
Signed-off-by: Alexey Neyman <stilor@att.net>
Allow cross-gdb and gdbserver. This requires removal of an explicit
check that disables gdbserver on android. However, the comment above
that check refers to exec_elf.h, which has been removed since API level
19. It builds fine with current selection of the sample (21). Only
build-tested, hope someone can give it a try and report back.
We can fine tune the check for GDB but I'll leave it for now.
Signed-off-by: Alexey Neyman <stilor@att.net>
- libpthread requires iteration over multilibs, unlike the core, it
does not detect and build multilibs by itself.
- Disable parallel builds for mingw-w64 components; until mingw-w64 core
builds clean, I am not trusting it.
- Make the list of tools to build configurable
- Turn on multilib in x86_64 sample.
- Make warnings about tuple less redundant. As in, "one WARN is enough,
no need to shout it three times".
- Messages about various steps/substeps are more aligned with the rest
of the components.
- Use 'make' instead of ${make} to invoke the companion make just built,
if applicable.
Signed-off-by: Alexey Neyman <stilor@att.net>
(see the comments in the code for details on the issue)
Old workaround in 100-gcc.sh stopped working (probably, due to one
of GCC version upgrades), so switch to the other approach originally
described there: adjust the list of multilibs to not include the
default target explicitly.
Signed-off-by: Alexey Neyman <stilor@att.net>
GCC does not distinguish the resulting binary by the CFLAGS (e.g. based
on which -march= was given). This means, while it will use the right
libraries for linking, at runtime they are all going to request the same
ld.so path and load the libraries from the same default path.
Signed-off-by: Alexey Neyman <stilor@att.net>
Hence, it is better to enforce via config rules: elf2flt does not
play nice with ld wrapper, when both ld.bfd and ld.gold are present.
Limit the choices to just 'ld.bfd' for flat-format architectures.
Signed-off-by: Alexey Neyman <stilor@att.net>
... that exhibited the issue with elf2flt configuration. Original reported
did not provide the config, and did not respond.
Signed-off-by: Alexey Neyman <stilor@att.net>
For that, make CT_BUILD_TOP_DIR a non-settable config option (so that it is
recursively expanded with CT_HOST/CT_TARGET). Use a common prefix, with
same default as for regular sample build.
Use showConfig.sh to determine host toolchain path (for canadian crosses)
and build directory to be removed.
Remove LIBC_SYSROOT_ARG (unused).
Signed-off-by: Alexey Neyman <stilor@att.net>
So that 'ct-ng saveconfig' works properly.
Also, run it through 'ct-ng saveconfig' so that default options are removed.
Signed-off-by: Alexey Neyman <stilor@att.net>
This follows the trend set by 1*.sh scripts that configure ISL, GMP,
MPFR, CLooG, etc. Building with shared libraries presents all kinds
of problems:
- The shared libraries need to be installed into ${CT_PREFIX_DIR}.
- The binaries linked against companion libs need to have proper
RPATH, or they're looking for shared libs in
.build/${CT_PREFIX}/buildtools/lib.
- All libraries must agree as to whether they're built shared,
static, or both. Otherwise, gettext tries to link in static libncurses.a
into a shared library and fails (since libncurses was compiled without
the -fPIC switch and hence contains relocations that cannot be handled
in a shared library).
So this fixes the current mess. If we decide to re-enable building
the companion libs shared, we should probably make this dependent on
a separate suboption of CT_STATIC_TOOLCHAIN.
Add a config loosely based on one reported in the issue 274.
Signed-off-by: Alexey Neyman <stilor@att.net>
This enables the resulting toolchaing to be used to build a canadian
cross to x86_64-pc-linux-gnu target. Unmark that sample as broken,
it now builds successfully.
It is likely that it is affected by issue #483, too - I see the
resulting gcc executable has a DLL dependency on libiconv-2.dll,
which is only installed into .build/.../buildtools. This will be
investigated/fixed separately.
Signed-off-by: Alexey Neyman <stilor@att.net>
Put xtensa core name to the tuple vendor string (without any overlay the
default core is 'fsf') and rename sample directory accordingly.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Add -mlongcalls and -mtext-section-literals to target CFLAGS. Target
libraries built with these flags have great call range, useful for linux
applications.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
To build uClibc correctly we need correct endianness selected in the
crosstool-NG. Xtensa cores may be little- or big-endian, but this
property is static. The toolchain knows the core endianness and doesn't
need options to select it.
Enable ARCH_SUPPORTS_BOTH_ENDIAN and select LE by default. Specify empty
CT_ARCH_ENDIAN_CFLAG so that -m{big,little}-endian don't get added to
the TARGET_CFLAGS, as it's not supported by gcc. Specify empty
CT_ARCH_ENDIAN_LDFLAG so that -EB/-EL don't get added to the
TARGET_LDFLAGS as they are ignored. Select big-endian in the example
xtensa-unknown-linux-uclibc configuration.
This fixes uClibc toolchain build for little-endian cores.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
