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>
Set the origin of the Linux tarballs to www.kernel.org in order to avoid
getting an empty string in menuconfig.
Signed-off-by: Egeyar Bagcioglu <egeyar.bagcioglu@oracle.com>
[cp: use kernel.org]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
* Do not assume a release has a tarball if src_release is set to "n".
* Do not assume versions in repositories are all experimental.
* Allow versions to define their default repository_branch,
repository_cset, repository_subdir and bootstrap.
* Do not expect mirrors, archive_filename, archive_dirname,
archive_formats and signature_format from a version if src_release
is set to "n".
* Add version_number to allow version names to be different than the
version number. When given, use version_number to compare against
the milestones.
Signed-off-by: Egeyar Bagcioglu <egeyar.bagcioglu@oracle.com>
Add building on MacOS X as part of the CI testing.
A few notes:
* We exclude mips64-unknown-linux-gnu as the linux kernel headers need
<byteswap.h> that is a GNU extension to build elf-entry.c and does
not exist on Mac OS X.
* We create a SPARSE image filesystem to ensure we have are doing the
builds in a case sensitive fs.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
When building aarch64-unknown-linux-gnu on MacOS X, aarch64-builtins.c
files doesn't build by default with clang on MacOS X. We need to pass
-std=gnu++11 when building the file for things to work with clang.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Expect that if there is a binutils 2.35.2 release these fixes will be
included in there, these are pulled out of the binutils-2_35-branch post
the 2.35.1 release.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Similar to commit 57679b5e ("Disable context functions for Thumb") when
building for thumb we need to unset UCLIBC_HAS_CONTEXT_FUNCS.
Fixes#1397
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Since glibc 2.27 glob interface was changed [1] and so
"glob" & "glob64" symbols require glibc 2.27+.
For us that means if we build Binutils on a machine with glibc 2.27+
produced binaries won't be any longer usable on machines with older
glibc.
As an example [2]: build on Ubuntu 18.04 (with glibc 2.27) and try to run
on CentOS 7.x (with glibc 2.17), you'll see this:
---------------------->8-------------------
ldd ld
ld: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by ld)
---------------------->8-------------------
Now given glob is not really used by Binutils itself (only needed by GDB)
and we build Binutils & GDB separately let's make at least Binutils
more portable.
In theory we may even try to do the same hack for GDB forcing it to use
imported glob implementation. But since GDB is now built strictly by C++
compiler we'll get waaay to many incompatibilities due to multiple changes
of C++ ABI in between GCC 7.5 of Ubuntu 18.04 and GCC 4.8.5 of CentOS 7.x,
so there's no point to even try.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=ccf970c7a77e86f4f5ef8ecc5e637114b1c0136a
[2] https://github.com/zephyrproject-rtos/sdk-ng/issues/280
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Currently the help for LOCAL_PATCH_DIR did not specify the tree layout
of custom patches directory. This commit adds such explanation.
For example, the bundled patches for GCC are placed under
packages/gcc/<gcc-version>, thus custom (local) GCC patches should be
placed under $LOCAL_PATCH_DIR/gcc/<gcc-version>.
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
While building a canadian toolchain for windows host (any target),
the build failed for m4 host companion_tool with a recent mingw-w64
(at least 7.0.0).
m4 needs stack smashing protection which is not part of mingw-w64 c
library and an explicit trigger to link w/ libssp is needed.
Signed-off-by: Florent Valette <florent.valette@gmail.com>
By setting glibc build system default_cflags to be empty before
building, we will enforce the build system to only use the crosstool-ng
CFLAGS when building glibc.
Properly solves the issue identified in #1396.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
Backport change from glibc upstream that defines RELEASE as stable
instead of release. This will at least cause the default_cflags to be
set to expected default values again.
Ref issue #1396, although the bigger issue of respecting crosstool-ng
CT_GLIBC_EXTRA_CFLAGS is most likely still not fixed.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
picolibc is another bare-metal C library, and so should be mapped
to CT_TARGET_SYS just like newlib does.
Signed-off-by: Keith Packard <keithp@keithp.com>
Add arc, mips64, riscv32, riscv64, s390, sh, sparc and xtensa builds to
CI job. Also add an arm-picolibc-eabi target.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
We get the build log via the artifact upload so having it in the action
output is redundant (it also tends to get suppressed anyway).
Signed-off-by: Chris Packham <judge.packham@gmail.com>
