summaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
2016-11-29Pass FOR_BUILD flags when building the pass-1/2 core GCC.Alexey Neyman1-7/+8
Current build passes {CFLAGS,LDFLAGS}_FOR_HOST - which breaks canadian cross (e.g. tried building for x86_64-unknown-linux-uclibc host). This dates back to the days of yore when CFLAGS were set directly in the do_gcc_core_backend (and that function is used as the final gcc's backend). do_gcc_core_backend is now passed with CFLAGS/LDFLAGS to use, so let the pass-1/pass-2/final-for-build steps pass the appropriate flags. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-11-22xtensa: fix endianness supportMax Filippov1-0/+2
To build uClibc correctly we need correct endianness selected in the crosstool-NG. Xtensa cores may be little- or big-endian, but this property is static. The toolchain knows the core endianness and doesn't need options to select it. Enable ARCH_SUPPORTS_BOTH_ENDIAN and select LE by default. Specify empty CT_ARCH_ENDIAN_CFLAG so that -m{big,little}-endian don't get added to the TARGET_CFLAGS, as it's not supported by gcc. Specify empty CT_ARCH_ENDIAN_LDFLAG so that -EB/-EL don't get added to the TARGET_LDFLAGS as they are ignored. Select big-endian in the example xtensa-unknown-linux-uclibc configuration. This fixes uClibc toolchain build for little-endian cores. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2016-11-22Give companion tools some love.Alexey Neyman6-32/+37
Allow selection of make/m4/... version. Support imports of new versions via addToolVersion.sh. Import newest versions of the companion tools. One non-trivial change is the handling of make versions. Existing code was not handling make companion tool as described (see the previous commit). However, since most modern systems have make 4.x, that previous commit made crosstool-ng always build make as a companion tool. This traces back to the commit dd15c93 from 2014. That commit's log message says that actually it was 3.81 which broke the build for certain component (it was originally breaking eglibc, but I noticed it was breaking current glibc on powerpc64), and introduced an option to force using 3.81 by "components that really need it". It looks like in 2.5 years we haven't seen any such components that really need make 3.81, and (given that make has already had a few releases since 3.81) we're unlikely to see them in the future. Hence, the configure check is changed from "exactly 3.81" to "3.81 or newer". In its current form, configure will accept make 3.80+, and will not require make as a companion tool for 3.81+. We might want to bump the latter check to even newer version given the claim from dd15c93. Killed COMP_TOOLS_make_3_81_NEEDED. Anyway, I retained 3.81 just in case; ditto for m4 1.14.3, autoconf 2.65 and automake 1.11.1. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-11-21Partially revert 6f8e89cb5ca061e899bf3feaaf3fecf30d366c3e.Alexey Neyman34-186/+186
The referenced commit replaced 'make' with '${make}' everywhere. This is wrong for at least the utilities that we may build as companion tools (make, libtool): this will always invoke the version detected by configure by supplying the absolute path. In other words, the wrappers in .build/tools/bin are not fallbacks - they are either temporary (in case a respective companion tool is built) or permanent redirectors. This is the reason why the PATH= has .build/*/buildtools/bin at higher precedence than .build/tools/bin; the latter has the versions detected by configure and the former has the versions built as companion tools. Revert the rest of the gang (grep/sed/...) for consistency. After all, we may decide to supply some of them as well (awk, for instance). Signed-off-by: Alexey Neyman <stilor@att.net>
2016-11-19comptools/make: Fix CT_COMP_TOOLS_make_gmake optionBernhard Walle1-1/+1
Commit 6f8e89cb5ca061e899bf3feaaf3fecf30d366c3e broke that option. Since ${make} points to /usr/bin/make, making the symlink from gmake to /usr/bin/make is obviously the wrong decision. gmake should link to our (old-versioned) self-built make. Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
2016-11-11Merge remote-tracking branch 'upstream/master'Dmitry Pankratov4-7/+69
2016-11-10Merge pull request #472 from stilor/unparallel-make-installBryan Hundven1-3/+12
Do not run 'make install' in parallel in GCC.
2016-11-10Merge pull request #452 from KirillSmirnov/janitorialAlexey Neyman1-1/+2
Janitorial: update patches
2016-11-10Do not run 'make install' in parallel in GCC.Alexey Neyman1-3/+12
Signed-off-by: Alexey Neyman <stilor@att.net>
2016-10-24Merge branch 'master' into janitorialBryan Hundven2-1/+7
2016-10-12Merge branch 'master' into static-libgcc-more-fixesAlexey Neyman2-1/+7
2016-10-07Fine-tune moving gcc libraries to sysroot.Alexey Neyman1-0/+12
1. Check if anything was installed outside sysroot; on some [baremetal only?] configurations GCC doesn't install anything to ${CT_PREFIX_DIR}/${CT_TARGET}/lib. 2. We need to create <sysroot>/lib/<multilib> if it doesn't exist (MUSL only installs in <sysroot>/usr/lib). 3. Do not move the linker scripts; elf2flt expects to find them in gcc's dir, not sysroot. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-10-05Fix m68k with uClibc-ng >= 1.0.15.Alexey Neyman1-0/+5
1.0.15 only kept a single LINUXTHREADS option, and renamed it, making it no longer option-compatible with uClibc. The option for "1.0.14 or later" version of uClibc-ng is not currently used; rename it to "1.0.15 or later" and use it to handle newer uClibc-ng's linuxthreads. m68k happens to be the only sample using linuxthreads. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-10-05Add uClibc-ng 1.0.17.Alexey Neyman1-1/+2
Also, support uClibc-ng in addToolVersion.sh Signed-off-by: Alexey Neyman <stilor@att.net>
2016-10-04Merge branch 'master' into janitorialKirill Smirnov1-2/+36
2016-10-04Merge branch 'master' into x86-muslAlexey Neyman1-2/+27
2016-10-03GCC uses multi_os_dir for libgcc, not multi_dir.Alexey Neyman1-1/+1
Signed-off-by: Alexey Neyman <stilor@att.net>
2016-10-02Fix issue #449.Alexey Neyman1-2/+27
After building final gcc, place the libraries in non-sysroot libs into sysroot. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-10-01Merge branch 'master' of https://github.com/crosstool-ng/crosstool-ngDmitry Pankratov27-786/+1335
2016-09-23Add a checkbox for libmpx build.Alexey Neyman1-0/+9
Disable libmpx for musl builds. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-09-22Merge branch 'master' into janitorialKirill Smirnov1-1/+2
2016-09-20elf2flt: do not treat warnings as errorsKirill K. Smirnov1-0/+1
elf2flt is configured with -Werror flag by default. Disable it. Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
2016-09-14build/glibc: Improve confusing commentKirill K. Smirnov1-1/+2
Up until cset 4e2227e8a5537a8553c503e55d2cb2190f2a0d2f there was an 'if' statement with a comment. The abovementioned changeset removed the conditional statement but the comment survived. Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
2016-09-13binutils: make symlinks in a consistent wayKirill K. Smirnov1-1/+1
On the stage "core gcc pass-2" the following layout is created: 1) buildtools/bin/TARGET-{ar,as,elf2flt,flthdr,ld,ld.bfd,ranlib,strip} 2) buildtools/TARGET/bin/{ar,as,elf2flt,flthdr,ld,ld.bfd,ranlib,strip} 3) x-tools/TARGET/bin/TARGET-{ar,as,elf2flt,flthdr,ld,ld.bfd,ranlib,strip} 4) x-tools/TARGET/TARGET/bin{ar,as,elf2flt,flthdr,ld,ld.bfd,ranlib,strip} where both (1) and (2) are symlinks to (3). This effectively renders core pass-2 gcc with elf2flt linker unusable. Related elf2flt discussion: https://github.com/crosstool-ng/crosstool-ng/pull/443 Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
2016-09-10internals: properly strip gdbserverKirill K. Smirnov1-1/+10
On mingw target gdbserver is suffixed with '.exe', thus plain 'strip gdbserver' fails. Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
2016-08-31Merge pull request #435 from KirillSmirnov/uclibcBryan Hundven1-1/+7
uClibc: improve managing shared libs
2016-08-31Merge pull request #429 from pedronavf/patch-1Bryan Hundven1-1/+3
Update x86.sh
2016-08-29uClibc: propagate SHARED_LIBS option.Kirill K. Smirnov1-0/+6
This patch synchronizes crosstool CT_SHARED_LIBS and uclibc HAVE_SHARED options. Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
2016-08-29uClibc: install native utilsKirill K. Smirnov1-1/+1
This change adds native ldd and ldconfig utils to sysroot. For glibc just 'make install' installs everything including utils. For uclibc there exists a separate goal 'install_utils'. Make it. Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
2016-08-26Merge pull request #431 from bhundven/fix_cross_build_toolsBryan Hundven1-2/+2
cross: Only make 'build tools' for the 'build'
2016-08-26Update config.guess and config.subBryan Hundven2-19/+34
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2016-08-26cross: Only make 'build tools' for the 'build'Bryan Hundven1-2/+2
For a cross-compiler, we only need to make the 'build tools' for the 'build'. We also build the 'build tools' for the 'host' when building a cross-canadian toolchain. Closes #430 Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2016-08-26Update x86.shPedro Navarro1-1/+3
Added additional x86 architectures, like core2, that also map to i686
2016-08-23Merge pull request #410 from jmlemetayer/fix_populateBryan Hundven1-0/+1
populate: Fix undefined awk
2016-08-23Merge pull request #422 from datacom-teracom/masterBryan Hundven1-1/+1
scripts/functions: fix log level in call to CT_DoLog
2016-08-23Merge pull request #402 from lundmar/fix_elf2flt_repoBryan Hundven1-1/+1
Update elf2flt git repository location
2016-08-23musl: Add multilib support.Alexey Neyman4-36/+77
Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23uClibc: move ldso check to post_cc.Alexey Neyman1-43/+54
It turns out that core GCC on binfmt architectures (m68k, for example) cannot produce the final executable (looks for ld.real in the wrong place). Need to wait for the final gcc to become available. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23Support multilib in sh/uClibc.Alexey Neyman4-217/+213
Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23Treat multiroots differently.Alexey Neyman2-17/+83
'ld' does not search for dependency libraries in multi_os_directory, so if there's both multi_os_directory and multi_root, and there is only one configuration in each multi_root, forgo the multi_os_directory suffix. Needed for sh4-multilib-linux-uclibc. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23First stab at multilib/uClibc.Alexey Neyman5-16/+273
Create a separate 'libc_backend_once', install headers into a subdirectory (different sets of headers are installed for 32- and 64-bit architectures), and create a symlink for the dynamic linker location expected by GCC. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23uClibc: Split configuration tweaker into per-arch functions.Alexey Neyman11-113/+174
Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23Change multilib functions to set the variable.Alexey Neyman7-57/+79
Rather than echo-ing the new value, set the value into the variable with the name passed as an argument (similar to CT_SanitizeVarDir). This allows to use CT_DoLog in these functions. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23libc/*.sh: Deprecate libc_check_config step.Alexey Neyman20-147/+94
This step was only used in uClibc. However, with upcoming multilib, the config management will have to be done for each variant differently, anyway. uClibc was the only user of libc_check_config step, as well as CT_CONFIG_DIR directory. Retire these. Two other clean-ups in uClibc.sh: - KERNEL_HEADERS check seems to be bogus, this config option is not present even in 0.9.30 - which is not supported already. - SHARED_LIB_LOADER_PREFIX was renamed to MULTILIB_DIR in 0.9.31, according to ChangeLog - and MULTILIB_DIR is passed from command line instead. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23uclibc: merge startfiles/final into single backend.Alexey Neyman1-160/+109
In preparation for multilib support, use the same "backend" model that is already employed by glibc and musl. Also, the verbosity setting descriptions were swapped. V=2 is actually less verbose than V=1: V=1 prints full commands, while V=2 prints 'CC <file> <defines>'. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23uClibc.sh: typo, local -> locale.Alexey Neyman1-13/+13
Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23glibc.sh: cleanupsAlexey Neyman1-55/+33
- Dump CT_LIBC_EXTRA_CC_ARGS: instead, treat CT_LIBC_EXTRA_CFLAGS as arguments to CC (or they are not applied to .S, for example). Combine them with multi_flags and CT_TARGET_CFLAGS in proper order. - Analyze thus combined flags to determine --with-fp/--without-fp. Don't need to check CT_ARCH_FLOAT - it is reflected in CT_TARGET_CFLAGS anyway. Check more soft/hard float options defined on different architectures. - Drop checking for endianness flags: they are not reflected in configure arguments in any way, and they're already present in CFLAGS (either via multi_flags or via CT_TARGET_CFLAGS). Besides, CT_ARCH_ENDIAN_OPT was actually called CT_ARCH_ENDIAN_CFLAG, so this was a no-op anyway. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23libc/*.sh: handle combinations of multilib root/dir.Alexey Neyman6-171/+197
Install startfiles for libc variants into the most specific combination (suffixed sysroot, if applicable + suffixed multi-os dir, if applicable). Install headers once in every suffixed sysroot (although it seems that GCC picks up headers from top-level sysroot, GCC manual claims that sysroot suffix affects headers search path). In uClibc, this requires a better sanitization of the directory: it creates symlinks from {sysroot}/usr/lib/{multi_os_dir} to {sysroot}/lib/{multi_os_dir} and to do so, it counts the number of path components in the libdir. This breaks if one of such components is `..' - symlinks contain an extra `../..' then. Since such sanitization had to be implemented anyway, use it in other places to print more sensible directory names. Also, fix the description of configure --host/--target per musl's configure help message (and its actual code). Signed-off-by: Alexey Neyman <stilor@att.net>
2016-08-23multilib: Determine which options may pass through.Alexey Neyman4-55/+220
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>