buildroot/package/glibc, branch 2016.08

glibc: remove additional occurrences of eglibc

2016-06-28T20:25:51+00:00

Signed-off-by: Thomas Petazzoni Reviewed-by: Romain Naour Acked-by: "Yann E. MORIN" Signed-off-by: Peter Korsgaard

Replace (e)glibc by glibc

2016-06-28T20:19:22+00:00

Following the removal of eglibc support, this commit replaces all occurences of "(e)glibc" by just "glibc". Most of the occurences are in package Config.in comments. In addition, when the form "an (e)glibc ..." was used, it is replaced by "a glibc ...". [Peter: add new efi* packages, s/uclibc/uClibc as suggested by Romain, systemd / liquid-dsp tweaks as suggested by Yann] Signed-off-by: Thomas Petazzoni Reviewed-by: Romain Naour Acked-by: "Yann E. MORIN" Signed-off-by: Peter Korsgaard

glibc: bump default to version 2.23

2016-06-27T19:13:57+00:00

Signed-off-by: Gustavo Zacarias Signed-off-by: Peter Korsgaard

glibc: remove eglibc hashes

2016-06-08T21:29:30+00:00

In commit 500de2598a4902a0e9ec53f7b475046ff17c6681, support for eglibc was removed, but forgot to remove the corresponding hashes from the hash file. This commit fixes this mistake. Reported-by: Arnout Vandecappelle Signed-off-by: Thomas Petazzoni

Merge branch 'next'

2016-06-01T15:55:16+00:00

Signed-off-by: Peter Korsgaard

toolchain: improve SSP logic

2016-05-23T19:07:24+00:00

Don't enable SSP support on external toolchains just because they use glibc or musl. Instead of that, make the external toolchains explictily declare if they support SSP or not. And also add a check to detect SSP support when using custom external toolchains. For internal toolchains we always enable SSP support for glibc and musl. Fixes: http://autobuild.buildroot.net/results/ac7c9b3ad2e52abfe6b79a80045e4218eeb87175/ Signed-off-by: Vicente Olivert Riera [Thomas: - remove uClibc-specific SSP check, since there is now a generic check being done. - send potential compilation errors caused by the SSP check to oblivion, in order to avoid causing confusion for the user. - add autobuilder reference.] Signed-off-by: Thomas Petazzoni

toolchain: remove eglibc support

2016-05-17T06:48:23+00:00

The eglibc support has been marked deprecated since 2015.08, so it's time to remove it. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

glibc: disable build of glibc 2.22 with gcc 6.x

2016-05-17T06:43:27+00:00

glibc-2.22 does not build with gcc 6.x. The first issues can be fixed by: - Using the same 0004-gcc6.patch as we're using with glibc 2.23 since Buildroot commit ab8de336eb39ae1cb019a72be65bd0504c86e527. - Backport glibc commit 5542236837c5c41435f8282ec92799f480c36f18 to fix strchr() build failure. But then, there are some more failures caused by the fact that numerous glibc files were not using modern prototypes in the function definitions, causing build failures such as: ../sysdeps/unix/sysv/linux/dl-openat64.c:26:1: error: 'openat64' defined as variadic function without prototype [-Werror] openat64 (dfd, file, oflag) ^~~~~~~~ In file included from ../include/fcntl.h:2:0, from ../sysdeps/unix/sysv/linux/dl-openat64.c:21: ../io/fcntl.h:214:12: note: previous declaration of 'openat64' was here extern int openat64 (int __fd, const char *__file, int __oflag, ...) ^~~~~~~~ This could be fixed by backporting glibc commit 9dd346ff431fc761f1b748bd4da8bb59f7652094, but this is a large commit, touching a significant number of files. We probably don't want to take this path, and instead making glibc 2.22 as not available with gcc 6.x seems like the right course of action. Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

toolchain-external: align library locations in target and staging dir

2016-04-25T20:46:28+00:00

The toolchain-external logic is roughly: - populate the staging dir by rsyncing the entire ${ARCH_LIB_DIR} and usr/${ARCH_LIB_DIR} from sysroot. - populate the target dir by explictly copying some libraries from sysroot into target/lib and some other libraries in target/usr/lib, the split being hardcoded into buildroot regardless of the location in the sysroot. This means that a library libfoo could be located in: staging/lib/libfoo.so target/usr/lib/libfoo.so When debugging an application that links against this library, gdb will fruitlessly search for 'usr/lib/libfoo.so' in staging, and then suggest to use 'set solib-search-path' which is a hack, really. To solve the problem, we need to make sure that libraries from the toolchain are installed in the same relative location in staging and target. Achieve this by: - replacing the convoluted search for libraries using for+find in sysroot with a simple find in staging. - determining DESTDIR for each library individually based on the location in staging. - treating LIB_EXTERNAL_LIBS and USR_LIB_EXTERNAL_LIBS equivalently These changes also allow for the removal of most arguments to copy_toolchain_lib_root in the method itself and their callers. Test procedure: - set configuration for a given toolchain - make clean toolchain - find output/target | sort > /tmp/out-before - apply patch - make clean toolchain - find output/target | sort > /tmp/out-after - diff -u /tmp/out-before /tmp/out-after The only changes should be some libraries moving from lib to usr/lib or vice versa. Notable examples being libstdc++ and libatomic. Signed-off-by: Thomas De Schampheleire Reviewed-by: Romain Naour Acked-by: Arnout Vandecappelle (Essensium/Mind) [Thomas: - use -L instead of -follow in the find invocation, as suggested by Arnout. - move the BR2_STATIC_LIBS condition as a make condition rather than a shell condition, as suggested by Arnout.] Signed-off-by: Thomas Petazzoni

package/glibc: add upstream patch to fix glibc-2.23 compile bug with gcc6

2016-04-24T21:28:48+00:00

Signed-off-by: Bernd Kuhls Signed-off-by: Thomas Petazzoni