On some arches (e.g. MIPS) the options like -mabi do not work if
specified more than once (see the comment in 100-gcc.sh). Therefore,
we need to determine which of the options produced by <arch>.sh can
be passed to multilib builds and which must be removed (i.e., which
options vary among the multilibs).
This presents a chicken-and-egg problem. GCC developers, in their
infinite wisdom, do not allow arbitrary multilib specification to be
supplied to GCC's configure. Instead, the target (and sometimes some
extra options) determine the set of multilibs - which may include
different CPUs, different ABIs, different endianness, different FPUs,
different floating-point ABIs, ... That is, we don't know which parts
vary until we build GCC and ask it.
So, the solution implemented here is:
- For multilib builds, start with empty CT_ARCH_TARGET_CFLAGS/LDFLAGS.
- For multilib builds, require core pass 1. Pass 1 does not build any
target binaries, so at that point, our target options have not been
used yet.
- Provide an API to modify the environment variables for the steps that
follow the current one.
- As a part of multilib-related housekeeping, determine the variable
part of multilibs and filter out these options; pass the rest into
CT_TARGET_CFLAGS/LDFLAGS.
This still does not handle extra dependencies between GCC options (like
-ma implying -mcpu=X -mtune=Y, etc.) but I feel that would complicate
matters too much. Let's leave this until there's a compelling case for
it.
Also, query GCC's sysroot suffix for targets that use it (SuperH,
for example) - the default multilib may not work if the command line
specifies the default option explicitly (%sysroot_suffix_spec is not
aware of multilib defaults).
Signed-off-by: Alexey Neyman <stilor@att.net>
Rather then building the manuals and locales for each multilib target, only
build the manuals on the last multilib target.
If you are not building a multilib toolchain, then the first libc build will
be the last.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
GCC makes the distinction between:
multilib (-print-multi-lib) and
multilib-os (--print-multi-os-directory)
as the GCC library and GCC sysroot library paths, respecitively.
Use this to build libc into the correct locations, the same
applies to the dummy libc.so
Changed by Alexey Neyman: restore missing CT_EndStep.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
The previous patch added the function 'CT_DoMultilibTarget()' to
scripts/build/arch/*.sh.
This patch calls the common function to (currently) get just the target
tuple for the current multilib target.
This patch was originally by: Cody P Schafer
Changed by Alexey Neyman: first, try `gcc -print-multiarch`. If it is
supported, use whatever it reports. Otherwise, fall back to our
guesswork. Move "i486" quirk into glibc.sh, as it is specific to glibc
(e.g. uclibc will need i386, which is what GCC reports).
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
If a multilib configuration contains an endianness option, the
${endian_extra} is set to, for example, 'mb' (note, no dash!). It is
then added to CFLAGS, resulting in bogus flags like 'mb -mb'. But it is
not even needed, as ${extra_flags} already contains the very same
option!
Found by experimenting with multilibs with different endianness on SH,
which still didn't work, but that's another story...
Signed-off-by: Alexey Neyman <stilor@att.net>
GLIBC 2.23 dropped support for pre-v9 SPARC in pthreads. Pass host
triplet with s/sparc/sparcv9/ replacement for 2.23.
Signed-off-by: Alexey Neyman <stilor@att.net>
This commit moves the do_libc_configure function to do_libc_backend and
switches do_libc_start_files and do_libc_final to call do_libc_backend.
The major reason for the rewrite is that musl => 1.1.13 has had it's own
build system rewritten and can now build out-of-tree.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
In do_libc_backend_once:
```
# Also, if those two are missing, iconv build breaks
extra_config+=( --disable-debug --disable-sanity-checks )
```
But in do_libc_locales we only add ```--disable-debug```.
This change adds ```--disable-sanity-checks``` to do_libc_locales to
mirror this, as I've seen iconv break this way.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
No point in calling an empty function. Must be left over from the
glibc/eglibc split up... then re-merge.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Since external add-ons were removed in 2.17, and we only support >=
2.18, this support is no longer needed.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Move crosstool-ng hook functions to be in the normal locations.
This commit has no functional changes.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit updates the build scripts to match the new usage of
CT_GetCustom from the previous change.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As per the change notes of GCC-6:
https://gcc.gnu.org/gcc-6/changes.html
and conversations I've had with the buildroot folks, there is no need
to support sh5/sh64.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
We check for apps:
* make
* sed
* grep
* awk
* libtool/libtoolize
* install
* patch
* and more
...during configure. Our scripts should be consistent about using the
variables that define where the found tool was found.
Of course, we do hard-link these tools in buildtools, but that should be
a backup for the components we are building. Our scripts should always
use the tools we find.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
The Xtensa processor architecture is a configurable, extensible,
and synthesizable 32-bit RISC processor core. Processor and SOC vendors
can select from various processor options and even create customized
instructions in addition to a base ISA to tailor the processor for
a particular application.
Because of the configurability, the build process requires one additional
step for gcc, binutils, and gdb to update the default configuration.
These configurations are packed into an 'overlay' tar image, and are
simply untarred on top of the default configuration during the build.
Signed-off-by: Max Filippov <jcmvbkbc@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>
I've added the .config files to contrib/uClibc-defconfigs from buildroot
to use as default configs if they are not provided in the sample.
If a particular architecture really needs an option set, it should be
either updated in the manange_uClibc_config function in
scripts/build/libc/uClibc.sh or a custom ${uclibc_name}.config should be
added to the sample (usually via `ct-ng saveconfig`).
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit updates uClibc to use the new CT_Kconfig options from the
previous commit. The older sed method of sanity checking the uClibc
.config was error prone and clumsy.
Signed-off-by: Bryan Hundven <bryanhundven@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>
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>
glibc-2.17 and above no longer have external addons or ports.
So if we are => 2.17, don't even think about trying to mess with ports
or addons.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit adds support for the avr-libc C library.
According to the project page at http://www.nongnu.org/avr-libc , the
avr-libc package provides a subset of the standard C library for Atmel
AVR 8-bit RISC microcontrollers. In addition, the library provides the
basic startup code needed by most applications.
Support for this library in crosstool-ng is only enabled for the AVR
8-bit target.
The avr-libc manual and most distributions build the AVR 8-bit gcc
toolchain with the "avr" (non-canonical) target.
Some experimentation also led to the conclusion that other (canonical)
targets are not very well supported, so we force the "avr" target for
crosstool-ng as well.
The manual also recommends building avr-libc after the final gcc build.
To accomplish this with crosstool-ng, a new do_libc_post_cc step is
added, in which currently only avr-libc performs its build, and is a
no-op for the other libc options.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
The argument will prevent the prefix path from being added as an include path while building mingw. Having the prefix as an include path might cause all kinds of weird issues if prefix directory also exists on the build machine.
Signed-off-by: Nils Petter Eftedal <nilspetter@eftedal.org>
Added new functions to support changes in prefix and required vendor tuple for new versions of mingw.
Tested and verified with mingw version 2.0.7, 3.3.0 and 4.0-rc3.
Signed-off-by: Nils Petter Eftedal <nilspetter@eftedal.org>
Glibc actually does create a build executable. It's under sunrpc and it's
called cross-rpcgen. It uses gettext, so if that's not available in a standard
place on your system (for example if you're using Mac OS X and Homebrew), then
you are all out of luck.
Signed-off-by: Lawrence D'Anna <larry@elder-gods.org>
Prirotize http downloads before ftp downloads.
By having http download first, those using proxy will work with the
current download mechnism.
This tells me that that mechnism needs to be updated.
(proxy support and/or kconfig toggles)
closes#3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
glibc versions that don't support --with-pkgversion or --with-bugurl
will cause a harmless:
====================
configure: WARNING: unrecognized options: --with-bugurl...`
====================
If it's set, use it, if it's a recognized option.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
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>
Require access to newlibs headers in gcc.sh, matching other libc components.
Resolves issue with headers not found.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Currently, the obsolete RPC headers are only installed for eglibc,
but glibc has the same /deficiency/, so install the obsolete RPC
for both.
Signed-off-by: Jérôme BARDON <bardon.pro@gmail.com>
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
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>
