glibc: nptl is default from 2.20, so dont add to addons_list

No longer recommended practice to use --enable-add-ons=nptl, so
for 2.20 and later (along with custom glibc), don't add the
CT_THREADS to the addons_list

https://sourceware.org/glibc/wiki/Release/2.20#Packaging_Changes

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
libc/glibc: Add CUSTOM version and CUSTOM_LOCATION config options and GetCustom

CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
libc/eglibc: Add CUSTOM version and CUSTOM_LOCATION config options and GetCustom

CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
libc/{,e}glibc: If using custom {e}glibc, dont extract or patch

If custom {e}glibc is being used, no need to carry out the
extract or patching phase of scripts/build/libc/glibc-eglibc.sh-common

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
libc/glibc: Always enable obsolete RPC for glibc and eglibc

Move outside the switch on eglibc/glibc to do for both.

Patch on mailing list, when applied, this will be dropped

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
cc/gcc: Remove copyheaders toggle in do_cc_core_backend, make default

Canadian Cross compile for baremetal fails with error;

  checking for the value of EOF... configure: error: computing EOF failed

which is due to libstdc++ configure not being able to find stdio.h

Having all modes of the core compiler copyheaders from CT_HEADERS_DIR
(in combination with previous patch for newlib to add a do_libc_start_files
function to copy into the CT_HEADERS_DIR) resolves this.

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
libc/newlib: Add do_libc_start_files to copy headers to CT_HEADERS_DIR

Require access to newlibs headers in gcc.sh, matching other libc components.

Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
scripts/glibc-eglibc.sh-common: broken symlinks created for nested multilib dirs

glibc-eglibc.sh-common prepares a number of symlinks for use in building C
Library, which is iterated through for each multilib combo, however there is a
hardcoded number of backsteps in the symlink command which assumes the multi_dir
is only 1 directory deep.

This means we are creating broken symlinks for nested multilib dirs, eg;

  gcc configured with these multilibs (besides the default):
  -mxl-barrel-shift  -->  bs/
  -mxl-barrel-shift -mno-xl-soft-mul  -->  bs/m/
  -mxl-barrel-shift -mno-xl-soft-mul -mxl-multiply-high  -->  bs/m/mh/

  multi_dir=bs;      ln -sf "../lib/bs" "bs/lib"           <- Ok
  multi_dir=bs/m;    ln -sf "../lib/bs/m" "bs/m/lib"       <- Broken
  multi_dir=bs/m/mh; ln -sf "../lib/bs/m/mh" "bs/m/mh/lib" <- Broken

In the Final C Library step, we perform a "Fixing up multilib location" stage,
which in each loop removes its temporary multi_dir - a problem with nested
multilib dirs, as the first loop may be for 'bs' say, which will remove the
'bs' directory, and the nested dirs for bs/m, bs/m/mh along with it, before
they have gone through their own do_libc_backend_once iteration.

The solution I propose is similar to how the build-libc-${libc_mode}
directories are created - replacing '/' with '_' and having a flat structure
for these temp multi_dirs

Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
cc/gcc: Add debug symbols option

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
binutils/binutils: Add debug symbols option

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
libc/{,e}glibc: Add debug symbols option

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
libc/common: Add endian multilib with the missing '-' and to dummy libc.so

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
cc/gcc.sh: Remove LDFLAGS_FOR_TARGET

When building multilib toolchain with an endian multi-lib,
LDFLAGS_FOR_TARGET configures the final compiler with the
default endian flag (eg -Wl,-EB) which is passed to the
multilibs and causes failures if that multilib is a different
endianness (eg -mlittle-endian)

Cant see a use for this option - no issues in standard builds?

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Samples: Add microblaze linux / baremetal samples based on custom source

Upstream samples for microblaze will have to point to release versions
of each component. These samples are for dev use, as they point to a local
custom source directory.

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Samples: microblaze(el) linux single lib, preset CFLAGS

Build microblaze(el) linux toolchains without
multi-lib, and the default libs should have CFLAGS set
to match Low End Linux profile in XPS

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Accomodate binutils-gdb merge by disabling unwanted component

Binutils and gdb are available as single binutils-gdb.git repository.
The master branch of this repository contains both;
  binutils-gdb/binutils
  binutils-gdb/gdb

Meaning that the SUBDIRS contains gdb while trying to build binutils
and vice versa.

Disable the unwanted side explicitly always.

Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>