instead of 'make oldconfig' and responding 'y'. This avoids 'Broken pipe'
errors in the log, as well as selects default setting for all options not
explicitly set.
This requires a small fix in the old uClibc. Won't have to maintain that fix
for long though :)
Signed-off-by: Alexey Neyman <stilor@att.net>
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.
uClibc's unifdef tool declares strlcpy(3) which is problematic on OS X. There
(and probably on other systems) strlcpy(3) is defined as a macro, re-declaring
it here will fail cause the macro expansion will generate an invalid function
name.
The declaration of strlcpy(3) is however useless cause it is never used in the
tool. Also upstream patch 2a021ae81c36f4281883a3195f7ce81504edf978 will remove
it. Using that patch here is overkill, cause it rewrites a lot of the
unifdef.c code.
Signed-off-by: Andreas Bießmann <andreas@biessmann.de>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
uClibc 0.9.33.2 has an issue related to __kernel_long and similar
types when building with kernel headers >= 3.4. This commit adds a
uClibc that fixes this issue, and allows building with recent kernel
headers.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This patch/workaround is similar to the one proposed in
http://www.mail-archive.com/uclibc@uclibc.org/msg02475.html
Bug reproduced with GCC 4.6.3.
[ALL ] In file included from libc/inet/inet_ntoa.c:8:0:
[ALL ] libc/inet/addr.c: In function 'inet_ntoa_r':
[ALL ] libc/inet/addr.c:135:1: warning: visibility attribute not supported in this configuration; ignored [-Wattri
butes]
[ERROR] libc/inet/addr.c:135:1: internal compiler error: in output_move_qimode, at config/m68k/m68k.c:3160
Signed-off-by: "Esben Haabendal" <esben@haabendal.dk>
Message-Id: <87sja4d1ke.fsf@arh128.prevas.dk>
Patchwork-Id: 187181
