aboutsummaryrefslogtreecommitdiff
path: root/scripts/build
Commit message (Collapse)AuthorAgeFilesLines
* Enable support for building libgccjitMarc Poulhiès2022-12-187-5/+44
| | | | | | | | | | | | | | | | | | | | | libgccjit is still under development and, despite its name, may also be used for ahead-of-time compilation. Documentation can be found on the gcc website: https://gcc.gnu.org/onlinedocs/jit/internals/index.html https://gcc.gnu.org/wiki/JIT With this change it's possible to enable the building of the libgccjit. It's enabled as a language (with --enable-languages=jit) even if not a language frontend at all. The main changes are related to the requirement of having everything host side built as Position Independent Code (PIC) with --enable-host-shared. GCC has the needed logic for building its dependencies (mpc, gmp, mpfr, ...) correctly when built "in-tree", which is not the case with crosstool-ng (see https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=05048fc29f0) Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
* Add BPF architecture target supportCupertino Miranda2022-12-141-0/+7
| | | | | | | | | BPF is a virtual machine and associated ISA that resides in the Linux kernel. Initially intended for user-level packet capture and filtering, BPF is nowadays generalized to serve as a general-purpose infrastructure also for non-networking purposes. Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com>
* scripts/gcc: Add extra include dir with -idirafterJoakim Nohlgård2022-12-111-1/+14
| | | | | | | | Fixes Canadian cross builds failing with missing include file 'stdio.h' when building libstdc++ for a companion libc with system libc set to LIBC_NONE. Signed-off-by: Joakim Nohlgård <joakim@nohlgard.se>
* scripts/gcc: align test conditionals with rest of repoJoakim Nohlgård2022-12-111-5/+4
| | | | | | | | | Most scripts in crosstool-ng use [ -z "${string}" ] to check for empty variables. Deleted one duplicate declaration of the local exec_prefix Signed-off-by: Joakim Nohlgård <joakim@nohlgard.se>
* binutils: add option to build libopcodes for targetDries Deschout2022-10-021-2/+3
| | | | | | It provides functionality to disassemble executable binaries. Signed-off-by: Dries Deschout <dries.deschout@dodeco.eu>
* cc/gcc: Use canon_prefix when dealing with moved librariesChris Packham2022-09-261-2/+2
| | | | | | | | | | | | ${CT_PREFIX_DIR} may contain relative paths (e.g. "${CT_TOP_DIR}/../x-tools/${CT_TARGET}"). Code added in commit d83a0036 ("Add symlinks from the libraries' original location to the new one.") didn't cope well with this. As we're already calculating ${cannon_prefix} make use of it when adding the symlinks. This avoids any issues with ${CT_PREFIX_DIR}. Fixes #1807 Signed-off-by: Chris Packham <judge.packham@gmail.com>
* Add CC_GCC_ENABLE_DEFAULT_PIELike Ma2022-08-191-0/+4
| | | | | | | | Enable Position Independent Executable as default Pass --enable-default-pie to crossgcc's configure Signed-off-by: Like Ma <likemartinma@gmail.com>
* loongarch64: add initial loongarch supportJiajie Chen2022-08-191-0/+5
| | | | | | | | | | | | This commit adds architecture support for LoongArch. The toolchain currently only supports the 64-bit target loongarch64-unknown-linux-gnu. It has been tested to build with GCC 12.1, GDB 12.1, Glibc 2.36, Linux 5.19 and Binutils 2.39 as of Aug 2022. Signed-off-by: Jiajie Chen <c@jia.je>
* Fixes for libstdcxx-verbose option tristateNorbert Lange2022-07-111-0/+2
| | | | | | | | Make it proper "tristate" by not specifying the option. The config GCC_4_8_or_later was removed with cc6b7fad46f5cb3d84, so dont use it.
* Allow libsanitizer on architectures that support itChris Packham2022-07-111-5/+5
| | | | | | | | | | | | libsanitizer is only supported on selected architectures. Add ARCH_SUPPORTS_LIBSANITIZER and have architectures select this option based on the list of supported configurations from GCC's libsanitizer/configure.tgt. Support for mips64 was added in GCC12 so this is an additional condition for the mips architecture. Fixes #1733 Signed-off-by: Chris Packham <judge.packham@gmail.com>
* Switch CT_CC_{CORE_}SYSROOT_ARG to arraysJustin Chen2022-07-011-1/+1
| | | | | | | CT_CC_{CORE_}SYSROOT_ARG is being used both as an array and string. Switch everything to be used as an array for consistency. Signed-off-by: Justin Chen <justinpopo6@gmail.com>
* glibc: configure adding debug symbols in glibc buildGuillermo E. Martinez2022-06-211-1/+5
| | | | | | | | | | After building the cross toolchain and compile a simple C program, objdump reports debug information even though -g modifier was not used. These debug segments are in glibc library and CRT files. So a new config entry: CT_GLIBC_ENABLE_DEBUG was added to control when we want to add debug information to glibc, by default is enabled. Signed-off-by: Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
* Enable D language supportMarc Poulhiès2022-06-141-0/+1
| | | | | | | Enable D support as an experimental feature. GDC becomes a build dependency when enabled. Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
* gcc: Fix compilation error in core C gcc compiler older than v5Guillermo E. Martinez2022-06-011-2/+8
| | | | | | | | | | | | | | | | | | | | | When core gcc older than v5 is compiled it shows the error message: Build failed in step 'Installing core C gcc compiler' called in step '(top-level)' Error happened in: CT_DoExecLog[scripts/functions@376] called from: do_gcc_core_backend[scripts/build/cc/gcc.sh@627] called from: do_cc_core[scripts/build/cc/gcc.sh@210] called from: main[scripts/crosstool-NG.sh@697] configure: error: in `.../build/build-cc-gcc-core/fixincludes': configure: error: C compiler cannot create executables This patch disable `all-build-libcpp' target when core gcc older than v5 is configured. Signed-off-by: Guillermo E. Martinez <guillermo.e.martinez@oracle.com>
* gmp: Set CC_FOR_BUILD and CPP_FOR_BUILDChris Packham2022-05-311-2/+5
| | | | | | | | | When GMP is being "cross" compiled for the same architecture (i.e. build == host) it does not pick the right compiler. Set CC_FOR_BUILD and CPP_FOR_BUILD to override the default compiler. Fixes #1328 Signed-off-by: Chris Packham <judge.packham@gmail.com>
* gcc: Add 12.1Chris Packham2022-05-191-2/+2
| | | | | | | | | | | | | | | | | | | Add GCC 12.1 https://gcc.gnu.org/gcc-12/ The following patches from GCC 11.3.0 are no longer needed: - 0005-arc-Update-ZOL-pattern.patch - 0006-arc-Update-u-maddhisi4-patterns.patch - 0007-arc-Fix-maddhisi-patterns.patch - 0008-Darwin-aarch64-Initial-support-for-the-self-host-dri.patch - 0009-libstdc-Check-for-TLS-support-on-mingw-cross-compile.patch One new patch is needed to avoid issues building sh-unknown-elf: - 0006-sh-Avoid-mb-m1-multilib-combination.patch It is also necessary to build all-build-libcpp. This target exists as far back as GCC 6 so has been done unconditionally. Signed-off-by: Chris Packham <judge.packham@gmail.com>
* glibc: Reinstate support for the bundled portsChris Packham2022-05-181-0/+3
| | | | | | | | | | | Commit 6d5227b6 ("Remove obsolete glibc 2.12.1") removed supports for the separate glibc-ports but also removed GLIBC_USE_PORTS_ADDON. Glibc versions up to 2.20 bundled support from some architectures in the ports directory so GLIBC_USE_PORTS_ADDON is required to support these older glibc versions. Fixes #1736 Signed-off-by: Chris Packham <judge.packham@gmail.com>
* duma: Add version 2.5.21Chris Packham2022-05-151-0/+1
| | | | | | | | | | | | Add duma 2.5.21 and mark 2.5.15 as obsolete. While we're at it use the versions hosted on github which requres new checksums for the 2.5.15 version because the generated tarballs are different. It appears we don't need any of the patches we've been carrying for the older version but we do need to pass CC_FOR_BUILD in addition to HOSTCC. When 2.5.15 is removed we can drop HOSTCC (and DUMA_CPP, DUMA_SO). Signed-off-by: Chris Packham <judge.packham@gmail.com>
* newlib-nano: Fix include path for CT_NEWLIB_NANO_INSTALL_IN_TARGETStephanos Ioannidis2022-05-121-1/+1
| | | | | | | | | | | | | | | | | | When `CT_NEWLIB_NANO_INSTALL_IN_TARGET=y`, the `nano.specs` file emitted by the newlib-nano build script contains an invalid include path, resulting in the full `newlib.h` being included instead of the nano `newlib.h` by the application. `=/include/newlib-nano` is not a valid path (`=` does not mean anything and that string is taken as an include path as-is) and GCC ignores this include path, resulting in application including the `newlib.h` from `include/` which contains the newlib build configurations for the full newlib. This commit modifies the newlib-nano build script to emit a proper newlib-nano include path relative to the `GCC_EXEC_PREFIX`. Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
* scripts/build/companion_libs: Fix missing directory with newlib-nanoDerald D. Woods2022-05-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With 'CT_NEWLIB_NANO_INSTALL_IN_TARGET=y', this build failure occurs: ---------------------------------------------------------------------- [...] [INFO ] Installing Newlib Nano library [EXTRA] Configuring Newlib Nano library [EXTRA] Building Newlib Nano C library [EXTRA] Installing Newlib Nano C library [INFO ] Installing Newlib Nano library: done in 110.66s (at 29:04) [INFO ] ================================================================= [INFO ] Installing libstdc++ newlib-nano [EXTRA] Configuring libstdc++ for newlib-nano [EXTRA] Building libstdc++ newlib-nano library [EXTRA] Installing libstdc++ newlib-nano library [EXTRA] Housekeeping for core gcc compiler [EXTRA] '' --> lib (gcc) lib (os) [EXTRA] ' -mthumb' --> lib/thumb (gcc) lib/thumb (os) [EXTRA] ' -marm -mfpu=auto -march=armv5te+fp -mfloat-abi=hard' --> lib/arm/autofp/v5te/fpu (gcc) lib/arm/autofp/v5te/fpu (os) [EXTRA] ' -mthumb -mfpu=auto -march=armv7+fp -mfloat-abi=hard' --> lib/thumb/autofp/v7/fpu (gcc) lib/thumb/autofp/v7/fpu (os) [INFO ] Installing libstdc++ newlib-nano: done in 457.12s (at 36:42) [ERROR] [ERROR] >> [ERROR] >> Build failed in step '(top-level)' [ERROR] >> [ERROR] >> Error happened in: CT_DoExecLog[scripts/functions@376] [ERROR] >> called from: newlib_nano_copy_multilibs[scripts/build/companion_libs/350-newlib_nano.sh@270] [ERROR] >> called from: CT_IterateMultilibs[scripts/functions@1608] [ERROR] >> called from: do_newlib_nano_for_target[scripts/build/companion_libs/350-newlib_nano.sh@254] [ERROR] >> called from: do_companion_libs_for_target[scripts/build/companion_libs.sh@43] [ERROR] >> called from: main[scripts/crosstool-NG.sh@697] Current command: 'cp' '-f' '/build/toolchain/arm-none-eabi/newlib-nano/arm-none-eabi/lib/thumb/libc.a' '/build/toolchain/arm-none-eabi/arm-none-eabi/lib/thumb/libc_nano.a' exited with error code: 1 Please fix it up and finish by exiting the shell with one of these values: 1 fixed, continue with next build command 2 repeat this build command 3 abort build ---------------------------------------------------------------------- This commit calls 'mkdir -p' to create the destination path before copying. Signed-off-by: Derald D. Woods <woods.technical@gmail.com>
* cc/gcc: Create liblto_plugin symbolic link with correct extensionJoel Holdsworth2022-05-111-4/+12
| | | | | | | | | | | | Previously, cc/gcc.sh assumed that liblto_plugin would always be installed with the ".so" file extension. However, this assumption is incorrect when the host machine is Windows (".dll") or MacOS (".dylib"). This patch corrects this issue by probing the file extension in similar fashion to the way adjacent code determines the file extension of executable binaries. Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
* cc/gcc: Ensure value of ext is always setJoel Holdsworth2022-05-111-2/+2
| | | | | | | | The "ext" variable is set with the file extension of executable binaries for a given platform. To improve tidiness, this patch ensures the variable is always set even when there is no file path. Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
* cc/gcc: Declare "file" and "ext" variables localJoel Holdsworth2022-05-111-0/+4
| | | | | | | | In do_gcc_core_backend and do_gcc_backend, variables "file" and "ext" are used to store intermediate values. Previously, these were not declared local. This patch corrects this issue. Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
* cc/gcc: Remove -lstdc++ and -lm from gcc LDFLAGSJoel Holdsworth2022-05-111-24/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In Bryan Hundven's patch 1ad439907 from 2010, the author added -lstdc++ and -lm to the host gcc build's LDFLAGS, because at the time the linker did not correctly include these libraries causing the build to fail. In modern builds, this causes a problem for canadian gcc builds where the host machine is mingw32-w64 Windows. Within the gcc build there is the liblto_plugin module. On Windows this must be built as the "liblto_plugin.dll" dynamic library. However, libtool cannot produce a dynamic library unless every library dependency is also a dynamic library, and falls back to producing a libstdc++.a static library. liblto_plugin does not require libstdc++ - it does not contain any C++ code, and the dependency would usually be elided by the linker. Unfortunately, in this case, crosstool-ng will never build a libstdc++.dll dynamic library - only a libstdc++.a static library. Therefore, there will never be a dynamic library version of stdc++ for libtool to load and then discard. This patch corrects the issue by removing "-lstdc++" from LDFLAGS, because modern versions of gcc are able to correctly include libstdc++ where necessary. It also remove "-lm" for similar reasons. Signed-off-by: Joel Holdsworth <jholdsworth@nvidia.com>
* gdb: drop obsolete versionsChris Packham2022-05-101-20/+0
| | | | | | | Drop gdb 7.11.1, 7.12.1, 8.0.1, 8.1.1 and 8.2.1. Cleanup milestones related to these older versions. Signed-off-by: Chris Packham <judge.packham@gmail.com>
* Remove obsolete glibc 2.12.1Chris Packham2022-05-101-17/+0
| | | | | | | | | glibc 2.12.1 was marked as obsolete. Now that the 1.25.0 release is out this version can be removed completely. As glibc 2.12.1 was the last remaining version supported by glibc-ports support for glibc-ports is also removed. Signed-off-by: Chris Packham <judge.packham@gmail.com>
* Remove obsolete bionic/android supportChris Packham2022-05-102-35/+0
| | | | | | | | The bionic libc support was out of date and relied on downloading binaries from the internet. It was already marked as obsolete. Now that the 1.25.0 release is out it can be completely removed. Signed-off-by: Chris Packham <judge.packham@gmail.com>
* gcc: add gcc libstdcxx-verbose optionNorbert Lange2022-02-231-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 <nolange79@gmail.com>
* binutils: Disable libdebuginfod when producing a static toolchainChris Packham2022-02-231-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 <judge.packham@gmail.com>
* Unify core passesAlexey Neyman2022-02-112-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 <stilor@att.net>
* Fold libc_start_files into libcAlexey Neyman2022-02-118-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 <stilor@att.net>
* Convert tabs to spacesAlexey Neyman2022-02-116-68/+68
| | | | | | | Recent changes introduced a mixture of tabs/spaces that result in broken indentation in multiple places. Signed-off-by: Alexey Neyman <stilor@att.net>
* Restrict *-uclibc,* canadians to gettext 0.20Alexey Neyman2022-02-111-0/+22
| | | | | | | Newer gettext is incompatible with uClibc-NG in cross-compilation, see the comment in the code. Signed-off-by: Alexey Neyman <stilor@att.net>
* Retire obsoleted milestonesAlexey Neyman2022-02-117-84/+31
| | | | | | | | | | | | ... 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 <stilor@att.net>
* gcc: Build static libgcc in core_pass1Chris Packham2022-01-121-0/+2
| | | | | | | | | | | | | | | | | | Per https://github.com/crosstool-ng/crosstool-ng/issues/808 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 <judge.packham@gmail.com>
* binutils: Remove obsolete versionsChris Packham2021-09-211-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 <judge.packham@gmail.com>
* gdb: Remove old milestonesChris Packham2021-09-211-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 <judge.packham@gmail.com>
* gmp: Support building for targetChris Packham2021-09-191-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 <judge.packham@gmail.com>
* Merge branch 'gdb-enable-tui' of ↵Chris Packham2021-09-191-4/+2
|\ | | | | | | | | | | https://github.com/foss-for-synopsys-dwc-arc-processors/crosstool-ng Signed-off-by: Chris Packham <judge.packham@gmail.com>
| * gdb: Enable TUI for full target/native GDBAlexey Brodkin2021-09-161-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 <abrodkin@synopsys.com>
* | gdb: Realy decouple building of native/target GDB & gdbserverAlexey Brodkin2021-09-191-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 <abrodkin@synopsys.com>
* Merge branch 'canadian-cross-build' of ↵Chris Packham2021-09-081-13/+1
|\ | | | | | | | | | | https://github.com/foss-for-synopsys-dwc-arc-processors/crosstool-ng Signed-off-by: Chris Packham <judge.packham@gmail.com>
| * gcc: Fix canadian cross building on older hostsAlexey Brodkin2021-09-061-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] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5329b59a2e13dabbe2038af0fe2e3cf5fc7f98ed [2] https://gcc.gnu.org/gcc-6/changes.html [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96612 [4] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7ffcf5d61174dda1f39a623e15f7e5d6b98bbafc [5] https://github.com/crosstool-ng/crosstool-ng/commit/9c6c090d7b6f5a03213b8ac6bd33a5cb812ec4c4 [6] https://github.com/crosstool-ng/crosstool-ng/commit/08161250ed65a9b91d680a305d01acd8052f937f Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
* | gcc: Don't mess with --with-host-libstdcxx if recent GCC (6+) is usedAlexey Brodkin2021-09-071-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] https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=5dc85f7ec719a79ecfbcdd8563b07e5f0f365e65 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092 Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
* cc/gcc: Add options for zstd usageChris Packham2021-08-291-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 <judge.packham@gmail.com>
* Merge branch 'uclibc-atomics' of ↵Chris Packham2021-08-251-17/+0
|\ | | | | | | | | | | https://github.com/foss-for-synopsys-dwc-arc-processors/crosstool-ng Signed-off-by: Chris Packham <judge.packham@gmail.com>
| * ARC: No more fiddling with uClibc's CONFIG_ARC_HAS_ATOMICSAlexey Brodkin2021-08-241-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 <abrodkin@synopsys.com>
* | Merge branch 'gdb-10' of https://github.com/cpackham/crosstool-ngChris Packham2021-08-251-30/+91
|\ \ | | | | | | | | | Signed-off-by: Chris Packham <judge.packham@gmail.com>
| * | gdb: Add gdb-10.2Alexey Brodkin2021-08-251-30/+91
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In GDB 10.x gdbserver was promoted to the top-level folder, see https://sourceware.org/git/?p=binutils-gdb.git;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 <abrodkin@synopsys.com> [cp: support old/new layout, regenerate patches] Signed-off-by: Chris Packham <judge.packham@gmail.com>
* / Add support for no-mmu microblazeSteve Bennett2021-08-251-1/+1
|/ | | | | | | no-mmu architectures need to be explicitly listed in CT_DoKernelTupleValues Signed-off-by: Steve Bennett <steveb@workware.net.au>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-21 02:35:49 +0000