path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
2022-02-23gcc: add gcc libstdcxx-verbose optionNorbert Lange1-0/+10
Rather important option for arm cortex toolchains supporting c++, avoids pulling in all printf/iostream code by default. Signed-off-by: Norbert Lange <>
2022-02-23binutils: Disable libdebuginfod when producing a static toolchainChris Packham1-0/+3
libdebuginfod is incompatible with static linking so pass --without-debuginfod when CT_STATIC_TOOLCHAIN is selected. Fixes #1683 Signed-off-by: Chris Packham <>
2022-02-11Unify core passesAlexey Neyman2-71/+16
With libc_headers step before pass-1, there is no need to distinguish pass-1 and pass-2; they are configured identically (note that with the current configuration, core pass-2 is only used for win32 - hence, uses build_libgcc=yes and mode=static). Signed-off-by: Alexey Neyman <>
2022-02-11Fold libc_start_files into libcAlexey Neyman8-338/+82
After 557b9d4, libc_start_files and libc_main steps are performed one after another. It doesn't make sense, especially since some of the libcs (glibc, uClibc-ng) go to great lengths to first install start files in the first step, libc_start_files, only to remove them immediately in the second step, libc_main. Current build steps also break in the xtensa newlib configurations, as it needs to install the custom xtensa headers before building the libgcc and after 557b9d4, the headers are not installed before libgcc is built in pass-1. Therefore, finish what 557b9d4 mentioned but did not do: move header installation into a new step, libc_headers, and combine libc_start_files and libc_main into a single step. This also allows to combine the core pass-1/pass-2 steps, to be done in a subsequent commit. Signed-off-by: Alexey Neyman <>
2022-02-11Convert tabs to spacesAlexey Neyman6-68/+68
Recent changes introduced a mixture of tabs/spaces that result in broken indentation in multiple places. Signed-off-by: Alexey Neyman <>
2022-02-11Restrict *-uclibc,* canadians to gettext 0.20Alexey Neyman1-0/+22
Newer gettext is incompatible with uClibc-NG in cross-compilation, see the comment in the code. Signed-off-by: Alexey Neyman <>
2022-02-11Upgrade script for uClibc retirementAlexey Neyman2-0/+16
Run samples through upgrade and fix accumulated breakages: *-centos6-*: After 2.12.2 retirement, the samples selected most recent glibc (2.34) which also forced kernels 3.2+. Revert to 2.12.1 and, respectively. Interestingly, 2.12.1 was marked as being used in CentOS6, but the samples selected 2.12.2. Anyway, CentOS6 is EOL now and glibc 2.12 is going to be marked obsolete, and retired soon. arc-*: Make TARGET_VENDOR match the sample's name; otherwise `ct-ng saveconfig` places the config file into a different location. Fix 'savedefconfig' which was not saving the configuration file version (CT_VCHECK was set to 'load' after CT_LoadConfig call). Signed-off-by: Alexey Neyman <>
2022-02-11Retire obsoleted milestonesAlexey Neyman8-85/+32
... and the code dependent on them, after the latest wave of obsolete package removals. This concludes the glorious history of the original uClibc (non-NG) with lots of kludges removed. There was a choice here, whether to call the resulting libc "uClibc" or "uClibc-ng". I opted in favor of giving uClibc-ng the recognition it deserves, although it had some ripple effect in the ct-ng code. Signed-off-by: Alexey Neyman <>
2022-01-12gcc: Build static libgcc in core_pass1Chris Packham1-0/+2
Per build static libgcc in the first pass which lets us skip the second one. Building mingw-w64 requires header files in order to build C++ support so mingw builds core pass 2. This could probably be cleaned up by splitting libc_start_files into a separate libc_header step. But for now having core 2 for mingw-w64 and core 1 for the other libcs will have to do. Anything that previously selected CC_CORE_PASSES_NEEDED now selects CC_CORE_PASS_1_NEEDED. The same goes for CC_CORE_PASS_2_NEEDED with the exception of mingw-w64. Fixes #808 Fixes #217 Signed-off-by: Chris Packham <>
2021-12-13Update config.{sub,guess}Chris Packham2-625/+705
Run `ct-ng updatetools` to pick up the latest config.{sub,guess} from upstream. This picks up support for some new architectures (e.g. loongarch) and some new variants of existing ones. There is some refactoring that makes the diff a bit larger but it's fairly easy to follow. Signed-off-by: Chris Packham <>
2021-09-21binutils: Remove obsolete versionsChris Packham1-26/+20
The following versions were marked obsolete in crosstool-ng-1.24.0, remove them. - binutils-linaro-2.23.2-2013.10-4 - binutils-linaro-2.24.0-2014.11-2 - binutils-linaro-2.25.0-2015.01-2 - binutils-2.23.2 - binutils-2.24 - binutils-2.25.1 Adjust the milestones now that the old versions have been removed. Signed-off-by: Chris Packham <>
2021-09-21gdb: Remove old milestonesChris Packham1-21/+17
Now that the oldest supported version of gdb is 7.11.1 we can make some parts of the build unconditional and remove the associated config vars. Signed-off-by: Chris Packham <>
2021-09-19gmp: Support building for targetChris Packham1-2/+30
Allow GMP to be build for the target. This will be needed by the up coming gdb-11. Signed-off-by: Chris Packham <>
2021-09-19Merge branch 'gdb-enable-tui' of ↵Chris Packham1-4/+2 Signed-off-by: Chris Packham <>
2021-09-19gdb: Realy decouple building of native/target GDB & gdbserverAlexey Brodkin1-0/+8
Back in the day gdbserver was treated as a subproject of GDB and even was located in "gdb/gdbserver" and so to build gdbserver we had to go into "gdb/gdbserver" and there run configure. That way full GDB was out of the picture. Now starting from GDB 10.1 where gdbserver was promoted to the top-level we're supposed to run top-level's configure script for all the tools provided by the unified binutils-gdb tree. That said if we only want to build gdbserver (and that's what we want since we build one tool at a build step) we have to be explicit: ----------------->8---------------- --enable-gdbserver --disable--gdb ----------------->8---------------- Ah, and so far we used to build full native GDB when only wanted gdbserver if it was GDB v10.x ;) Ironically full native/target GDB also enabled gdbserver by default so we need to also disable it explicitly with "--disable-gdbserver". Signed-off-by: Alexey Brodkin <>
2021-09-16gdb: Enable TUI for full target/native GDBAlexey Brodkin1-4/+2
Since we have curses built for target anyway now, why don't allow users to use very convenient pseudo-GUI operating mode? And while at it, there's no use of TUI in naturally headless gdbserver. Signed-off-by: Alexey Brodkin <>
2021-09-08Merge branch 'canadian-cross-build' of ↵Chris Packham1-13/+1 Signed-off-by: Chris Packham <>
2021-09-07gcc: Don't mess with --with-host-libstdcxx if recent GCC (6+) is usedAlexey Brodkin1-8/+12
"--with-host-libstdcxx" option was removed in GCC 6.x, see [1] because of [2]. So it makes no sense to use it with later GCC versions. Frankly I don't like that implementation with yet another set of "if XXX", but since we still support GCC down to 4.8.5 what else we may do? Well, technically we may keep using things as they are now, because surprisingly GCC's configure script doesn't mind accepting meaningless options, but as a person who's looking at differences between various builds and drill-down to peculiarities of various config options, I'd prefer to not pollute configure with garbage. But for all the rest... well, it works now and maybe nodody else cares. [1];h=5dc85f7ec719a79ecfbcdd8563b07e5f0f365e65 [2] Signed-off-by: Alexey Brodkin <>
2021-09-07gcc: Fix canadian cross building on older hostsAlexey Brodkin1-13/+1
GCC 11+ requires compiler being used to support C++11 standard [1]. And while GCC starting from 6.x has C++11 support enabled by default [2], older versions need to be forced to implement it with "-std=gnu++11" and luckily GCC's build-system takes care of that: 1. For ${host} compiler - [1] 2. For ${build} compiler - [3, 4] In a nutshell the configure script tries a couple of options and the one which helps to build a test source gets appended to CXX (not CXXFLAGS!), so on say CentOS 7.x with GCC 4.8.5 during cross-compilation of GCC CXX="x86_64-build_pc-linux-gnu-g++ -std=gnu++11". And all is good. But in case of canadian cross due to [5] we for some reason* force set CXX_FOR_BUILD with just a compiler name, effectively overriding all the magic done by GCC's internals described above. This leads to a compilation failures like that: ------------------------------------->8---------------------------------- [ALL ] In file included from /usr/include/c++/4.8.2/type_traits:35:0, [ALL ] from .../HOST-x86_64-apple-darwin14/arc-gcc11-elf/src/gcc/gcc/system.h:244, [ALL ] from .../HOST-x86_64-apple-darwin14/arc-gcc11-elf/src/gcc/gcc/gengtype.c:26: [ERROR] /usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options. [ALL ] #error This file requires compiler and library support for the ^ ------------------------------------->8---------------------------------- * my guess that [5] was done because back in the day indeed we used to have "--build=${CT_BUILD} --host=${CT_HOST}" in do_cc_core(). But now after [6] this is no longer necessary as we use "--build=${CT_BUILD} --host=${CT_BUILD}" and all is safe and clean. So yet another old quirk goes away - hooray! [1];a=commit;h=5329b59a2e13dabbe2038af0fe2e3cf5fc7f98ed [2] [3] [4];a=commit;h=7ffcf5d61174dda1f39a623e15f7e5d6b98bbafc [5] [6] Signed-off-by: Alexey Brodkin <>
2021-08-29cc/gcc: Add options for zstd usageChris Packham1-0/+5
GCC can support using zstd compression for LTO object files. By default GCC's configure will enable this if libzstd is installed on the machine building the toolchain. This may be undesirable if the toolchain is to be used on a different machine. Add an option to control zstd usage and set the default to the same as the current behaviour (i.e. auto). Fixes #1579 Signed-off-by: Chris Packham <>
2021-08-25Merge branch 'uclibc-atomics' of ↵Chris Packham1-17/+0 Signed-off-by: Chris Packham <>
2021-08-25Merge branch 'gdb-10' of Packham1-30/+91
Signed-off-by: Chris Packham <>
2021-08-25Add support for no-mmu microblazeSteve Bennett1-1/+1
no-mmu architectures need to be explicitly listed in CT_DoKernelTupleValues Signed-off-by: Steve Bennett <>
2021-08-24gdb: Add gdb-10.2Alexey Brodkin1-30/+91
In GDB 10.x gdbserver was promoted to the top-level folder, see;a=commit;h=919adfe8409211c726c1d05b47ca59890ee648f1 Which means it is no longer a subfolder in "gdb" and so we have to build gdbserver now exactly in the same way as normal native GDB. One interesting detail is gdbserver doesn't need to deal with target description in .xml so it doesn't depend on libexpat on target, thus we need to move libexpat explicit selection from do_gdb_backend() to its callers when building native [full] gdb as well as cross-gdb for the host. Signed-off-by: Alexey Brodkin <> [cp: support old/new layout, regenerate patches] Signed-off-by: Chris Packham <>
2021-08-24ARC: No more fiddling with uClibc's CONFIG_ARC_HAS_ATOMICSAlexey Brodkin1-17/+0
Older ARC700 processors had atomic instructions (AKA llock/scond) as an option and so quite some "atomic" operations were not possible w/o OS support, which we implemented - see arc_usr_cmpxchg() in the Linux kernel. And in uClibc, which was the only Linux libc back in the day of ARC700 era, it is well supported. Well, uClibc could be configured to support it. Which is done with CONFIG_ARC_HAS_ATOMICS Kconfig option. But the problem is there's no check for ARC ISA version in uClibc when this option gets enabled. That leads to a funny situation when even for ARCv2 processors (ARC HS3x & HS4x) uClibc tries to utilize arc_usr_cmpxchg() syscall which is not supported for this newer ISA since ARCv2 processors have atomic instructions built-in all the time. So what was happening here we didn't specify additional "-matomic" CFLAG unless we were targeting exactly those ancient ARC770 processors (ARC700 + MMUv3 + atomics) and so even for ARCv2 we forced uClibc to not use built-in atomics. And even though there're ways to add a smarter solution here to handle that pretty rare by now case of ARC750 (ARC700 + MMUv2 - atomics), I suggest we just remove this part completely, leaving a possibility to add needed option in uClibc-ng's configuration (I mean "packages/uClibc-ng/config"). Signed-off-by: Alexey Brodkin <>
2021-08-22gnuprumcu: Bump to v0.6.0Dimitar Dimitrov1-5/+4
Changes since v0.5.0: * Add spec files for am64x SoCs. * Require Binutils at least version 2.37. * Require pru-gcc to be installed. * Remove linker scripts. Instead set memory sizes from specs. * Activate --gc-sections linker option by default. * The "--host=pru" configure option must be used instead of "--target=pru. Signed-off-by: Dimitar Dimitrov <>
2021-07-30newlib-nano: Fix nano.spec based on CT_NEWLIB_NANO_INSTALL_IN_TARGETKumar Gala1-1/+28
The spec file was missing replacing various libs like libc, libm, etc with their nano equiv when CT_NEWLIB_NANO_INSTALL_IN_TARGET=y. Update the nano.spec file that is generated to rename libc, libm, etc if CT_NEWLIB_NANO_INSTALL_IN_TARGET=y Signed-off-by: Kumar Gala <>
2021-07-18Merge pull request #1561 from keith-packard/picolibc-1.7.1Chris Packham1-0/+1
Picolibc 1.7.1
2021-07-18Merge pull request #1560 from stephanosio/upstream_local_common_patch_dirChris Packham1-3/+5
Support common local patch directory
2021-07-18Disable source-highlighting for static buildQBos071-0/+6
Fixes #1487
2021-07-13picolibc: Disable wchar_t use in libstdc++Keith Packard1-0/+1
Picolibc doesn't support wchar_t in stdio, so disable the use of these functions from libstdc++. Signed-off-by: Keith Packard <>
2021-07-13Support common local patch directoryStephanos Ioannidis1-3/+5
This commit updates the patching process such that the local patches can be applied in a version-independent manner, as with the patches provided by the crosstool-ng packages. This is done by reading the patch files from `${CT_LOCAL_PATCH_DIR}/(package_name)` rather than from `${CT_LOCAL_PATCH_DIR}/(package_name)/(version)`. Signed-off-by: Stephanos Ioannidis <>
2021-07-11Merge pull request #1551 from rcatolino/add_extra_cxx_flagsChris Packham3-7/+12
2021-07-06Add EXTRA_CXXFLAGS_FOR_BUILD optionRaphael Catolino3-7/+12
Signed-off-by: Raphael Catolino <>
2021-07-06CT_Mirrors: make use of kernel cdnChris Packham1-6/+5 automatically redirects to a geographically close mirror. Make use of this instead of or While were at it make sure we use https. Signed-off-by: Chris Packham <>
2021-06-24Fix build of older Glibc using GCC >=10Nik Konyuchenko1-0/+4
Issue #1535 GCC 10 changed the default to -fno-common, which leads to a linking error in GLibc older than 2.30. This change adds -fcommon cflag for the target GLibc versions <=2.29 and GCC >=10. This change also adds additional cflags for the target GLibc to disable new GCC11 checks that lead to compilation errors. Signed-off-by: Nik Konyuchenko <>
2021-06-19gcc: Make CC_GCC_TM_CLONE_REGISTRY tristateChris Packham1-10/+10
Explicitly passing --disable-tm-clone-registry causes gcc to create a crtbegin.o with a zero-sized .init_array/.fini_array. This in turn causes ld to complain. Make CC_GCC_TM_CLONE_REGISTRY a tristate so if it's not explicitly enabled we can let ./configure decide. Fixes #1531 Fixes: 1e21a302 ("gcc: Add CT_CC_GCC_TM_CLONE_REGISTRY config") Signed-off-by: Chris Packham <>
2021-06-09Merge pull request #1524 from ↵Chris Packham2-5/+39
stephanosio/gcc_custom_libstdcpp_cxx_flags_upstream Fix libstdc++ build options
2021-06-07gcc: Add CT_CC_GCC_TM_CLONE_REGISTRY configStephanos Ioannidis1-0/+12
This commit adds a new gcc config `CT_CC_GCC_TM_CLONE_REGISTRY` that enables the GCC transactional memory clone registry feature for libgcc. Note that the gcc option to control this feature is only available in gcc 10 and above. (see gcc commit 5a4602805eb3ebddbc935b102481e63bffc7c5e6) Signed-off-by: Stephanos Ioannidis <>
2021-06-07newlib: Add libstdc++ nano-specific CXXFLAGSStephanos Ioannidis1-0/+3
This commit adds a new config that can be used to specify the target CXXFLAGS specific to the libstdc++ newlib-nano variant. By default, this config is set to specify the `-fno-exceptions` option, which disables C++ exception handling support and greatly reduces the compiled binary size. Signed-off-by: Stephanos Ioannidis <>
2021-06-07gcc: Allow setting custom target CXXFLAGSStephanos Ioannidis1-3/+26
This commit adds two additional arguments (`cxxflags_for_target` and `extra_cxxflags_for_target`) for the gcc backend build function that can be used to specify custom target CXXFLAGS. By default, the target CXXFLAGS is set to the target CFLAGS. When `cxxflags_for_target` is specified however, it overrides that behaviour and allows setting different target CXXFLAGS from the target CFLAGS. The `extra_cxxflags_for_target` argument can be used to specify the extra target CXXFLAGS to be appended to the target CXXFLAGS. This is useful when it is necessary to append CXX-specific flags to the existing CFLAGS to be used as the target CXXFLAGS. A useful application of this is building full and nano versions of libstdc++ with different target CXXFLAGS as necessitated by `nano.specs`. Signed-off-by: Stephanos Ioannidis <>
2021-06-07gcc: Assume '-O2' by default for building gcc target librariesStephanos Ioannidis1-3/+11
The gcc target libraries (e.g. libstdc++) are currently built without any optimisation flag when `CT_CC_GCC_ENABLE_TARGET_OPTSPACE` is not enabled and default to `-O0` unless user explicitly specifies an optimisation flag. This commit updates the gcc build script to assume `-O2` for building target libraries unless user provides a different optimisation flag. Note also that this is the default behaviour for gcc when C[XX]FLAGS_FOR_TARGET is not overridden. Signed-off-by: Stephanos Ioannidis <>
2021-05-06scripts/functions: Add better support for annotanted git tagsChristoph Muellner1-1/+7
Annotated git tags are git objects with their own ID. They contain the commit ID where they point to. When downloading from annotated tags, we currently get the following warning: "Revision being fetched changed to ${new_unique_id};" The old unique_id is the ID of the annotated tag and the new unique_id is the commit it points to. Let's resolve this by first assuming to have an annotated tag and let git ls-remote dereference it. If that fails (e.g. if it can't be dereferenced because it is not an annotated tag), then let's proceed as before and don't do any dereferencing. Signed-off-by: Christoph Muellner <>
2021-04-19Merge branch 'abrodkin-newlib-nano-relocatable' of ↵Chris Packham1-3/+3
2021-04-19Merge branch 'newlib-nano-target' of git:// Packham1-1/+26
2021-04-16newlib-nano: Use run-time calculated paths in top-level nano.specsAlexey Brodkin1-3/+3
In currently generated top-level "nano.specs" we resolve paths during toolchain building and then use those pre-defined full paths once the toolchain got built. That's OK until the toolchain is used right were it was built, otherwise paths used in the top-level "nano.specs" become irrelevant and linker fails to find "nano" libs reverting to non-"nano" libs in the default location. See Signed-off-by: Alexey Brodkin <>
2021-04-15newlib-nano: Add option to copy libs into targetKumar Gala1-0/+25
Add an option that will install a copy of newlib-nano lib*.a file in the target dir but renamed with a nano.a suffix (eg: libc_nano.a) as some default nano.spec files from newlib expect this setup. Additionally the newlib-nano version of newlib.h will get copied to include/newlib-nano/newlib.h. Signed-off-by: Kumar Gala <>
2021-04-15newlib-nano: remove whitespace from nano.spec fileKumar Gala1-1/+1
Remove trailing whitespace from generated nano.spec file. Signed-off-by: Kumar Gala <>
2021-04-15gdb: Don't mess with gdbserver config permissionsAlexey Brodkin1-5/+0
Some really old GDB releases did have gdbserver's configure script w/o execution permissions, so there was a need in the fix. As per Yann most likely it could have been true for GDB versions in between v5.3 & 6.6. Moreover it could have been fixed on re-release of GDB tarballs done in 2011, see [1]. And given we no longer support such old GDB versions in CT-NG (as of today we have 6.8 - 9.2, moreover it's not clear which of 6.8-7.x versions are still being actively used) we'll revert that old hack for now in a hope that it won't hurt anybody. Though if somebody sees that problem again we'll be able to revert this again ;) [1] Signed-off-by: Alexey Brodkin <>
2021-03-29build: debug: strace: Add -D__USE_MISC to target CFLAGSChris Packham1-1/+1
Similar to commit ca45a8f9 ("Add -D__GLIBC__ to target CFLAGS") newer versions of strace bundle the kernel headers which cause build errors such as: [ALL ] In file included from /home/x-tool/.build/arm-unknown-linux-musleabi/src/strace/bundled/linux/include/uapi/linux/in6.h:26, [ALL ] from /home/x-tool/.build/arm-unknown-linux-musleabi/src/strace/bundled/linux/include/uapi/linux/if_bridge.h:19, [ALL ] from /home/x-tool/.build/arm-unknown-linux-musleabi/src/strace/src/rtnl_mdb.c:16: [ERROR] /home/x-tool/.build/arm-unknown-linux-musleabi/src/strace/bundled/linux/include/uapi/linux/libc-compat.h:109: error: "__UAPI_DEF_IN6_ADDR_ALT" redefined [-Werror] [ALL ] 109 | #define __UAPI_DEF_IN6_ADDR_ALT 1 [ALL ] | [ALL ] In file included from /home/x-tool/.build/arm-unknown-linux-musleabi/src/strace/src/rtnl_mdb.c:15: [ALL ] /home/x-tool/x-tools/arm-unknown-linux-musleabi/arm-unknown-linux-musleabi/sysroot/usr/include/netinet/in.h:401: note: this is the location of the previous definition [ALL ] 401 | #define __UAPI_DEF_IN6_ADDR_ALT 0 [ALL ] | [ALL ] cc1: all warnings being treated as errors By defining __USE_MISC we get __UAPI_DEF_IN6_ADDR_ALT defined in a compatible manner. Signed-off-by: Chris Packham <>