I was going to start doing some autoconf work, and noticed that
configure.in was executable. Then I noticed Makefile.in was executable.
o.O
So, I ran ```find . -type f -executable``` and found a bunch of files
that shouldn't be set executable.
This commit makes them normal files again.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit sync gcc patches with buildroot.
I found this useful for fixing a few uClibc related issues.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
.. they're needed for the RPC generation in glibc
on both Cygwin and MinGW-w64.
Neither are built on GNU/Linux and iconv is not
built on Darwin.
Two patches for gettext are needed, one so that
-O0 works and one so that static builds can be
made.
They can take a good while to build, so if not
needed for_host or for_build then they are not
built.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
AM_PROG_LEX sets this for some weird reason; it should
look for a program only and not a library. Then later
it gets linked to ar, ranlib, dlltool, windres, windmc
and itbl-test despite nothing in the code #include'ing
FlexLexer.h
This isn't a big deal but it did cause a build failure
on Cygwin as it triggered a bug with their flex package
dependencies which I reported at:
https://www.cygwin.com/ml/cygwin/2015-10/msg00433.html
Arguably I should remove all traces of LIBLEX in each
Makefile.am instead?
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
pthread_mutextattr_settype -> pthread_mutexattr_settype
.. I'm not sure why this didn't fail everywhere, unless
no one has tried to build gold?
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
This commit removes blackfin support.
I'm open to re-adding blackfin after crosstool-1.23.0 is released, but
it is currently too difficult to port forward to newer versions of gcc
and uclibc.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Commit 1a25115a18 deleted non-GCC related
files, including the patch for uClibc to compile with Linux kernels after
3.4.
uClibc 0.9.30 patches are not restored by this change (0.9.30 is broken
with recent kernels for multiple other breakages in addition to that; if
not retired, it needs to be fixed properly).
Signed-off-by: Alexey Neyman <stilor@att.net>
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>
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.
Support binutils 2.25.1 in configuration.
Note: The patches do apply, but I didn't check the resulting tools.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
This changeset fixes an 'incomplete type struct siginfo' error when
attempting to build gcc-4.5.3 for mipsel.
Signed-off-by: Ben Gardiner <ben.l.gardiner@gmail.com>
Distribution avr toolchains commonly add a patch to binutils' size to
enable a custom "-C" option that shows AVR memory usage.
This patch is specific to the AVR architecture.
In order to make the crosstool-ng AVR toolchain compatible with existing
distribution toolchains, this patch is necessary.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
With newer version of the patch program, it no longer follows symlinks:
========================================================================
a/patch-2.7.4-x86_64-1.txz: Upgraded.
Patch no longer follows symbolic links to input and output files.
This
ensures that symbolic links created by git-style patches cannot cause
patch to write outside the working directory.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1196
(* Security fix *)
========================================================================
This copies patches/glibc/2.20 to patches/glibc/linaro-2.20-2014.11.
This change also closes#51
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This functionality was provided so that crosstool-ng could have a
further set of patches considered experimental and unsupported.
Now that musl-libc support is making it's way upstream in gcc, I'm
removing this support and the experimental musl patches.
In later commits, backports from gcc upstream will be added to the
supported patch sets to support musl-libc.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This actually comes from upstream:
https://sourceware.org/ml/libc-alpha/2014-09/msg00317.html
It is needed for plain glibc as well as linaro's version.
A symlink is added for the latter's version 2.20-2014.11.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
As posted on http://www.eglibc.org/
====================
EGLIBC is no longer developed and such goals are now being addressed
directly in GLIBC.
====================
I'm not interested in maintaining build support for unsupported
software.
Older branches of crosstool-ng continue to have eglibc support.
If you find issues with older branches, I'm always open to pull
requests.
Removing eglibc also frees up glibc cleanup and build optimization.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
