summaryrefslogtreecommitdiff
path: root/scripts/build/libc
AgeCommit message (Collapse)AuthorFilesLines
2016-08-23multilib: Determine which options may pass through.Alexey Neyman1-3/+19
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>
2016-08-23glibc: Build manuals and locales lastRay Donnelly1-3/+17
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>
2016-08-23glibc.sh: Use --print-multi-os-directoryAlexey Neyman1-41/+44
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>
2016-06-10glibc.sh: build dummy libc.so with correct extra flagsAlexey Neyman1-1/+2
Signed-off-by: Alexey Neyman <stilor@att.net>
2016-06-10glibc: Use common arch call to get multilib targetsRay Donnelly1-1/+18
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>
2016-06-10glibc: do not add bogus optionsAlexey Neyman1-2/+2
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>
2016-04-02Unbreak sparc-unknown-linux-gnu.Alexey Neyman1-2/+17
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>
2016-03-08newlib: add option to enable nano formatted ioBryan Hundven1-0/+3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2016-03-08newlib: add option to enable nano mallocBryan Hundven1-0/+3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2016-03-08newlib: disable multilib if it is not enabledBryan Hundven1-0/+5
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2016-03-01musl-libc: Rewrite musl.sh build scriptBryan Hundven1-50/+67
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>
2016-02-24glibc: Mirror extra_config flags from do_libc_backend_onceBryan Hundven1-0/+1
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>
2016-02-24glibc: remove do_libc_locales_extract; it's emptyBryan Hundven1-10/+0
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>
2016-02-24glibc: Remove support for downloading and extracting add-onsBryan Hundven1-67/+0
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>
2016-02-24glibc: reformat glibc build scriptBryan Hundven1-66/+64
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>
2015-12-08scripts: Update usage of CT_GetCustomBryan Hundven5-55/+15
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>
2015-11-23uClibc: Add kconfig option to enable IPv6 supportBryan Hundven1-0/+7
This commit adds a kconfig option to enable IPv6 support. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-11-21uClibc: remove references to sh64*Bryan Hundven1-1/+0
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>
2015-11-17consistency: Use exported variables of required toolsBryan Hundven6-52/+52
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>
2015-11-13xtensa: add support for the configurable Xtensa architecture.Chris Zankel1-0/+9
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>
2015-11-13Merge pull request #239 from diorcety-ctng/cc-cygwin-mingw-linuxBryan Hundven1-0/+14
Canadian cross build = x86_64 Cygwin host = x86_64 MinGW_W64 target = x86_64 GNU/Linux
2015-11-13Add gettext and libiconv as companion libsRay Donnelly1-0/+14
.. 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>
2015-11-13uClibc: Fall back to default configs if not providedBryan Hundven1-1/+4
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>
2015-11-13uClibc: Add support for uClibc-ngBryan Hundven1-10/+17
This commit adds uClibc-ng 1.0.8. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-11-13uClibc: rewrite mungeuClibcConfig to manage_uClibc_configBryan Hundven1-219/+177
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>
2015-11-11uClibc: Reduce supported versionsBryan Hundven1-8/+1
This commit reduces the number of supported versions to: * 0.9.33.2 * custom location Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-11-11Disable parallel build of mingw-w64-crt.Alexey Neyman1-1/+4
Unfortunately, parallel build issue is not yet fixed in current mingw-w64 sources. Signed-off-by: Alexey Neyman <stilor@att.net>
2015-11-10blackfin: Remove blackfin supportBryan Hundven1-1/+0
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>
2015-11-03uClibc: Don't use CROSS, use CROSS_COMPILE insteadBryan Hundven1-9/+9
As per: http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/Makefile.help?id=044843f002f666db3bc06c513ed6291a00ad1225 CROSS= is for compatibility, but we plan on dropping older uClibc versions, and adding uClibc-ng and uClibc-snapshot support. Use CROSS_COMPILE instead. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-10-31gcc: Support only the latest branch releases of gccBryan Hundven1-19/+0
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>
2015-09-14Added additional newlib specific target flags with new optionJasmin Jessich1-1/+4
LIBC_NEWLIB_TARGET_CFLAGS. Signed-off-by: Jasmin Jessich <jasmin@anw.at>
2015-09-02glibc: Fix applying addons to glibc => 2.17Bryan Hundven1-25/+27
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>
2015-06-21avr-libc: add support for avr-libc C libraryErico Nunes7-0/+95
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>
2015-05-12mingw-w64: Add 'devel' version to use git 'master' branchRay Donnelly1-13/+23
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
2015-04-14Merge pull request #57 from smoofra/buildflagsBryan Hundven1-0/+4
bugfix: pass extra build CFLAGS and LDFLAGS to glibc
2015-04-14Merge pull request #63 from neftedal/masterBryan Hundven1-3/+28
Updated script to support mingw versions above major 2
2015-04-08mingw.sh: added with sysroot argument to mingw configureNils Petter Eftedal1-0/+1
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>
2015-04-08mingw.sh: updated script to support mingw versions above major 2Nils Petter Eftedal1-3/+27
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>
2015-04-08bugfix: pass extra build CFLAGS and LDFLAGS to glibcLawrence D'Anna1-0/+4
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>
2015-04-08Merge pull request #37 from bhundven/so_long_to_eglibcBryan Hundven3-739/+530
So long to eglibc
2015-02-02scripts/*/*.sh: prioritize http downloadsBryan Hundven2-1/+3
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>
2015-01-28glibc: Fix pkgversion and bugurl supportBryan Hundven1-1/+6
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>
2015-01-28eglibc: Remove eglibc supportBryan Hundven3-739/+525
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>
2015-01-16libc: newlib: Add NewLib 2.2.0, Linaro NewLib 2.2.0-2015.01 and 2.1.0-2014.09Cristoforo Cataldo1-2/+9
This commit allows to choose, download and build latest NewLib: - newlib-2.2.0 - newlib-linaro-2.2.0-2015.01 - newlib-linaro-2.1.0-2014.09 Signed-off-by: Cristoforo Cataldo <cristoforo.cataldo@gmail.com>
2015-01-16libc: glibc: Add Linaro GLibc 2.20-2014.11Cristoforo Cataldo1-3/+11
This commit allows to choose, download and build latest Linaro GLibC: - glibc-linaro-2.20-2014.11 Signed-off-by: Cristoforo Cataldo <cristoforo.cataldo@gmail.com>
2015-01-16libc: eglibc: Add Linaro EGLibc 2.19-2014.08Cristoforo Cataldo1-0/+9
This commit allows to choose, download and build latest Linaro EGLibC: - eglibc-linaro-2.19-2014.08 Signed-off-by: Cristoforo Cataldo <cristoforo.cataldo@gmail.com>
2015-01-01libc/newlib: Add do_libc_start_files to copy headers to CT_HEADERS_DIRDavid Holsgrove1-4/+4
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>
2014-12-16Merge pull request #14 from davidholsgrove/glibc_rpcBryan Hundven1-2/+3
libc/glibc: install obsolete RPC for both eglibc and glibc
2014-12-15libc/glibc: install obsolete RPC for both eglibc and glibcJérôme BARDON1-2/+3
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>
2014-12-09libc/{,e}glibc: If using custom {e}glibc, dont extract or patchDavid Holsgrove1-3/+9
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>
generated by cgit v0.10.2-6-g49f6 at 2024-05-11 13:12:47 (GMT)