Age | Commit message (Collapse) | Author | Files | Lines |
|
As per:
http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/Makefile.help?id=044843f002f666db3bc06c513ed6291a00ad1225
CROSS= is for compatibility, but we plan on dropping older uClibc
versions, and adding uClibc-ng and uClibc-snapshot support.
Use CROSS_COMPILE instead.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
|
Some architectures, like arc and blackfin set CROSS_COMPILE to a default
if it is not set on the command-line.
Since we are building the cross-compiler, we need to ALWAYS set
CROSS_COMPILE, since building/checking headers is done after the GCC
PASS1 step.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
|
gcc: Support only the latest branch releases of gcc
|
|
config: MIPS64 is no longer experimental
|
|
This is a weird artifact from when mips64 was first introduced to ct-ng
and was never removed from experimental.
If you have problems building a mips64 toolchain, please report on the
mailing list or on github issues.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
|
This change, as per #222, reduces the number of supported releases of
gcc to the latest branch releases.
I noticed while doing this work that gcc-4.5.4 was never added, so I
moved patches for gcc-4.5.3 to 4.5.4 and updated the
bfin-unknown-linux-uclibc example. Also, 120-siginfo.patch was fixed
upstream in the 4.5.4 release, so this patch is omitted.
I also bumped the avr sample to 4.9.3 from 4.9.2.
With the addition of gcc-5.x, the gcc release team now releases the
major.minor.0 versions, while updates to the branch are available in
svn/git. We'll address that when we get to issue #219. This change just
removes CC_GCC_5_1 and moves CC_GCC_5_2 to CC_GCC_5, and removes
CC_GCC_5_1_or_later and moves CC_GCC_5_2_or_later to CC_GCC_5_or_later.
This is the first of two part changes, as mentioned in #222.
This change is slated for release in 1.22.0. The next change will be
slated for 1.23.0, and will limit gcc versions to what is on
https://gcc.gnu.org under "Release Series and Status", which is
currently 4.9.3 and 5.2.0, although I will also support the previous
supported version. In this example that would be 4.8.5.
Last, but not least, this change also retires AVR32 support.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
|
scripts/config.{sub,guess}: Update from upstream
|
|
Update config.sub and config.guess from:
* git://git.sv.gnu.org/config.git
See their gitweb:
* http://git.savannah.gnu.org/gitweb/?p=config.git
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
|
Unbreak nios2-elf-mingw32 sample
|
|
Mark broken: i586-mingw32msvc,i686-none-linux-gnu.
|
|
There are no multilibs in GCC configured for this arch.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
Building cross-gdb in canadian cross requires expat/ncurses for the
host. Currently, 300-gdb.sh only builds expat/ncurses for the target
(for native-gdb). For cross-gdb on regular cross (build==host), expat
and ncurses are expected to be provided by the host.
There are two approaches possible:
- If building for canadian cross, build expat/ncurses for cross-gdb
just as the native-gdb does.
- Promote expat/ncurses to first class citizens and build them as
companion libs during the build of the build-to-host toolchain.
I am leaning towards the latter approach - it would also allow to
specify the versions for expat/ncurses rather than have them hardcoded
in 300-gdb.sh - but would appreciate feedback.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
Target does not have libz/zlib.h.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
Error message:
[EXTRA] Preparing working directories
[ERROR] Missing: 'i586-mingw32msvc-ar' or 'i586-mingw32msvc-ar' or 'ar': either needed!
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
Ltrace
|
|
Having *.la in the installation directory breaks ltrace: in ltrace,
libtool somehow considers libsupc++ to be an "accessory library" and
does not add -lsupc++ to the link flags. Neither Ubuntu, nor RedHat
include *.la files into their packages for libstdc++.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
This reverts commit a3bb2aeb4445bef4250acaaff99fc8dbb0599f8b.
|
|
musl-libc: backport gcc-6 musl support, add gdb and strace patches
|
|
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
|
This gets gcc and friends working with musl-libc.
GDB and Strace patches come from openwrt.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
|
bhundven/binutils_gold_conflicts_with_static_toolchain
binutils: Gold conflicts with Static Toolchain
|
|
Fix avr sample
|
|
linux: Update linux kernel versions
|
|
Update current stable and long-term releases:
* 4.2 -> 4.2.3
* 4.1.6 -> 4.1.10
* 3.18.20 -> 3.18.22
* 3.14.51 -> 3.14.54
* 3.12.47 -> 3.12.49
* 3.10.87 -> 3.10.90
* 3.4.108 -> 3.4.109
* 3.2.71 -> 3.2.72
* 3.6.32.67 -> 3.6.32.68
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
|
musl-libc: update musl-libc mainline to 1.1.12
|
|
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
|
The gold linker cannot currently be built in a static toolchain build.
This may get fixed in a future version of crosstool-NG.
Also, there is a bit of weirdness here. versions of binutils >= 2.21
have GOLD (BINUTILS_HAS_GOLD), but that doesn't mean it should be used.
For instance, if the architecture is not supported.
So with that, we create a new hidden option: BINUTILS_GOLD_SUPPORT
Which in turn depends on BINUTILS_GOLD_SUPPORTS_ARCH, BINUTILS_HAS_GOLD,
and not STATIC_TOOLCHAIN... then replace anything that previously
depended on BINUTILS_HAS_GOLD with our new BINUTILS_GOLD_SUPPORT option.
This closes #210
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
|
Fix option names in powerpc-e500v2 sample.
|
|
Fix link error in arm/uclibc with GCC 5.x
|
|
Missing include in glibc-2.22 for sparc32/nptl.
|
|
Trivial avr32 fix: name of config option has changed
|
|
Restore sh4-unknown-linux-gnu sample.
|
|
|
|
The issue with this sample is that the sh4-* targets in GCC do not
implement __builtin_trap() function. Starting with release 5.1,
GCC inserts abort() calls where NULL pointers are dereferenced. The
elf/dl-conflict.c in glibc is one such place: it calls elf_machine_rela
with NULL `sym' pointer. This causes an undefined `abort' symbol to
appear in the object file and as a result, pulls in some files during
the linking of the dynamic loader that are not supposed to. Eventually,
it results in link error due to multiple definitions of _itoa and some
other symbols.
The right fix would be to implement __builtin_trap() for sh4 in GCC.
A workaround would be adding -fno-delete-null-pointer-checks to
CFLAGS-dl-conflict.c in elf/Makefile. Until either of these happens,
though, pin the GCC version to 4.9.3 - the last that did not generate
`abort' calls. Note that the version where GCC started to generate
`abort' calls is apparently different for different architectures;
the issue in [1] was reported against GCC 4.9.
References:
[1] https://www.sourceware.org/ml/libc-alpha/2014-10/msg00807.html
(similar issue on HP-PA which was resolved by implementing
__builtin_trap)
|
|
|
|
Options were renamed. However, matching current option names result
in a compile error for strfmon_l.o in glibc: GCC 4.6 detects an
unitialized variable in its own va_arg() implementation. Likely,
an older GLIBC was used when this sample was submitted - which did
not provide -Werror in CFLAGS.
Thus, use most recent GCC (5.2.0) and revert GLIBC_FORCE_UNWIND to
its default value, 'y' (as forced unwind is required with this version).
|
|
- Incompatible ISL/CLooG were requested by config after newer releases
of both were brought in.
- Consistency with other samples: save tarballs (which will avoid
downloading them each time from Travis), extra logging.
|
|
|
|
This should ideally be upstreamed to uclibc maintainers, but with the
last release more than 3 years ago, I wouldn't hold my breath for a
fix being released any time soon.
|
|
Fix a typo in the documentation
|
|
Using "all" and "install" targets in do_gcc_core_backend if configured
|
|
Remove CC_GDB_CUSTOM from the version choice
|
|
Restore blackfin sample
|
|
Replace "now" with "know."
|
|
- New configurations:
- CC_GCC_TARGET_FINAL:
Use the default targets "all" and "install" for the final compiler for
bare metal.
- Adding parameter "build_step" to function do_gcc_core_backend:
do_gcc_core_backend is used for the core compiler and in case of bare metal
for the final compiler, too. To have better control over the parameters for
the final compiler "build_step" is used.
- Used for proper logging.
- Use CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY or CT_CC_GCC_EXTRA_CONFIG_ARRAY.
- If CT_CC_GCC_TARGET_FINAL is set and the final compiler is build then the
make targets for the final compiler are used ("all", "install").
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
|
|
Synchronize CC_GCC_USE_LTO parameter setting II
|
|
Add additional environment variables for gcc build.
|
|
Adding missing if/else blocks in do_gcc_core_backend.
|
|
Manage Travis-CI build
|