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>
Before patches for specific package were searched in
packages/${pkg_name}/${version}. This means that with usage of custom
version, patches wont be applied. This commit makes ct-ng search bundled
patches also in packages/${pkg_name} directory. That means that we can
put some patches in this directory, that will be applied to any version
of this component.
Make --enable-obsolete-rpc conditional on !CT_GLIBC_2_32_or_later as
it's been removed from that version on.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
