aboutsummaryrefslogtreecommitdiff
path: root/scripts/build
Commit message (Collapse)AuthorAgeFilesLines
...
| * 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>
* gnuprumcu: Bump to v0.6.0Dimitar Dimitrov2021-08-221-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 <dimitar@dinux.eu>
* newlib-nano: Fix nano.spec based on CT_NEWLIB_NANO_INSTALL_IN_TARGETKumar Gala2021-07-301-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 <kumar.gala@linaro.org>
* Merge pull request #1561 from keith-packard/picolibc-1.7.1Chris Packham2021-07-181-0/+1
|\ | | | | | | Picolibc 1.7.1
| * picolibc: Disable wchar_t use in libstdc++Keith Packard2021-07-131-0/+1
| | | | | | | | | | | | | | Picolibc doesn't support wchar_t in stdio, so disable the use of these functions from libstdc++. Signed-off-by: Keith Packard <keithp@keithp.com>
* | Disable source-highlighting for static buildQBos072021-07-181-0/+6
|/ | | | Fixes #1487
* Add EXTRA_CXXFLAGS_FOR_BUILD optionRaphael Catolino2021-07-062-7/+10
| | | | Signed-off-by: Raphael Catolino <raphael.catolino@gmail.com>
* Fix build of older Glibc using GCC >=10Nik Konyuchenko2021-06-241-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 <spaun2002mobile@gmail.com>
* gcc: Make CC_GCC_TM_CLONE_REGISTRY tristateChris Packham2021-06-201-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 <judge.packham@gmail.com>
* Merge pull request #1524 from ↵Chris Packham2021-06-092-5/+39
|\ | | | | | | | | stephanosio/gcc_custom_libstdcpp_cxx_flags_upstream Fix libstdc++ build options
| * newlib: Add libstdc++ nano-specific CXXFLAGSStephanos Ioannidis2021-06-071-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 <root@stephanos.io>
| * gcc: Allow setting custom target CXXFLAGSStephanos Ioannidis2021-06-071-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 <root@stephanos.io>
| * gcc: Assume '-O2' by default for building gcc target librariesStephanos Ioannidis2021-06-071-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 <root@stephanos.io>
* | gcc: Add CT_CC_GCC_TM_CLONE_REGISTRY configStephanos Ioannidis2021-06-081-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 <root@stephanos.io>
* Merge branch 'abrodkin-newlib-nano-relocatable' of ↵Chris Packham2021-04-191-3/+3
|\ | | | | | | git://github.com/foss-for-synopsys-dwc-arc-processors/crosstool-ng
| * newlib-nano: Use run-time calculated paths in top-level nano.specsAlexey Brodkin2021-04-161-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 https://github.com/crosstool-ng/crosstool-ng/issues/1491. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
* | Merge branch 'newlib-nano-target' of git://github.com/galak/crosstool-ngChris Packham2021-04-191-1/+26
|\ \
| * | newlib-nano: Add option to copy libs into targetKumar Gala2021-04-151-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 <kumar.gala@linaro.org>
| * | newlib-nano: remove whitespace from nano.spec fileKumar Gala2021-04-151-1/+1
| |/ | | | | | | | | | | Remove trailing whitespace from generated nano.spec file. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
* / gdb: Don't mess with gdbserver config permissionsAlexey Brodkin2021-04-151-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] https://sourceware.org/legacy-ml/gdb/2011-09/msg00002.html Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
* build: debug: strace: Add -D__USE_MISC to target CFLAGSChris Packham2021-03-301-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 <judge.packham@gmail.com>
* Extend CC_GCC_LIBSSP with manual stateIvan Kukhta2021-03-171-10/+10
| | | | Signed-off-by: Ivan Kukhta <Ivan.Kukhta@acronis.com>
* newlib-nano: Create symlinks for nano-suffixed libsAlexey Brodkin2021-02-191-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If existing board's .specs are used for linking of a user's application, then instead of normally used libs like libc.a & libstdc++.a might be requested their "nano"-suffixed siblings: libc_nano.a, libstdc++_nano etc. That way: ----------------------------->8--------------------------- %rename link_gcc_c_sequence myboard_link_gcc_c_sequence *myboard_libc: %{!specs=nano.specs:-lc} %{specs=nano.specs:-lc_nano} *link_gcc_c_sequence: %(myboard_link_gcc_c_sequence) --start-group %G %(myboard_libc) --end-group ----------------------------->8--------------------------- Our companion newlib-nano libs are all built optimized for size, so we'd like to use them for linking. But given linker will see "-lc_nano -lstdc++_nano" on its command line non-suffixed libs will be ignored. To solve it we create those "_nano"-suffixed libraries as simple symlinks to existing libs.. Fixes https://github.com/crosstool-ng/crosstool-ng/issues/1458. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
* Merge pull request #1448 from dinuxbg/masterChris Packham2021-01-252-0/+94
|\ | | | | Add PRU target configuration
| * Add package with PRU linker scripts and headersDimitar Dimitrov2021-01-191-0/+89
| | | | | | | | | | | | | | | | Include the gnuprumcu package in PRU cross toolchain. Toolchain is somewhat useless without device specs and linker scripts for the various SoCs. Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
| * Add PRU cross tool targetDimitar Dimitrov2021-01-191-0/+5
| | | | | | | | | | | | | | | | | | Add sample configuration for building cross toolchain for the TI PRU. PRU cores are present in many of the BeagleBone single board computers. More information about the PRU can be found in https://bbb.io/pru Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
* | newlib-nano: Build libstdc++ against newlib-nano if requestedKeith Packard2021-01-141-0/+45
| | | | | | | | | | | | | | This uses the gcc support for building libstdc++ using alternate lib header files. Signed-off-by: Keith Packard <keithp@keithp.com>
* | Create nano.spec file that sits atop the existing nano buildKeith Packard2021-01-141-0/+16
| | | | | | | | Signed-off-by: Keith Packard <keithp@keithp.com>
* | Add newlib-nano as companion libKeith Packard2021-01-141-0/+128
|/ | | | | | | This allows building newlib-nano in addition to newlib and picolibc, allowing users to select between C libraries within the same toolchain. Signed-off-by: Keith Packard <keithp@keithp.com>
*-. Merge branches 'elijahr-dtc-1.6.0', 'elijahr-readme-typo', ↵Chris Packham2021-01-133-18/+156
|\ \ | | | | | | | | | 'foss-for-synopsys-dwc-arc-processors-abrodkin-libgmp-for-mac' and 'keith-packard-picolibc-companion'
| | * picolibc: Build libstdc++ against picolibc if requestedKeith Packard2021-01-111-0/+46
| | | | | | | | | | | | | | | | | | | | | This uses the gcc support for building libstdc++ using alternate lib header files. Signed-off-by: Keith Packard <keithp@keithp.com>
| | * gcc: Add support for building libstdc++ with alternate libcKeith Packard2021-01-111-7/+77
| | | | | | | | | | | | | | | | | | | | | This adds another mode to do_gcc_core_backend that builds libstdc++ against an alternate libc implementation. Signed-off-by: Keith Packard <keithp@keithp.com>
| | * picolibc: Convert to companion libraryKeith Packard2021-01-081-12/+25
| | | | | | | | | | | | | | | | | | | | | This allows configurations to include picolibc without excluding another C library. Signed-off-by: Keith Packard <keithp@keithp.com>
| * | libgmp: Fix cross-canadian build for macOSAlexey Brodkin2020-12-231-0/+9
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when building cross-canadian toolchain for macOS the folowing error happens when GCC is configured: |ld: illegal text-relocation to '___gmp_binvert_limb_table' in |... /.build/... /buildtools/complibs-host/lib/libgmp.a(mp_minv_tab.o) from '___gmpn_divexact_1' in |... /.build/... /buildtools/complibs-host/lib/libgmp.a(dive_1.o) |collect2: error: ld returned 1 exit status Apparently this might be solved with GMP configured with "--with-pic", even though we're talking about static library here. That solution was found here: https://github.com/Homebrew/homebrew-core/pull/25470 Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
* / gcc: Make it aware of Newlib nano IO featureAlexey Brodkin2020-12-231-0/+5
|/ | | | | | | | | | | | | | | | | | | | | | Even though GCC as a compiler has nothing to do with a C library being used it still makes sense to know about Newlib's compact implementation of IO functions: * For targets like MSP430 which require to have such a tuned Newlib if "-mtiny-printf" is passed to the GCC's command-line [1] * For correct compilation of the following GCC's own DejaGnu tests [2]: - gcc/testsuite/gcc.c-torture/execute/920501-8.c - gcc/testsuite/gcc.c-torture/execute/930513-1.c - gcc/testsuite/gcc.dg/torture/builtin-sprintf.c - gcc/testsuite/gcc.c-torture/execute/ieee/920810-1.x [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=02afb6a9321fbfb435452636cedc2cd43f0c4fd2 [2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=571bbd0d48d5872eacbd0b681fce6e1ae754520b So we add that missing cross-dependency now. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
* Merge pull request #1342 from DspHack/feature/add_support_for_ti_c6xChris Packham2020-11-102-1/+80
|\ | | | | Experimental: Add support for the Texas Instruments C6X (TMS320C6000 …
| * c6x: Remove multilib requirementDan Tejada2020-11-021-2/+0
| | | | | | | | | | | | | | Restore tuple config check Add sample configuration Signed-off-by: Dan Tejada <dan.tejada@cantada.com>
| * Experimental: Add support for the Texas Instruments C6X (TMS320C6000 series) ↵Dan Tejada2020-05-202-1/+82
| | | | | | | | | | | | | | | | | | | | DSPs -- c6x: Add support for c6x product families to pass on to uClibC-ng -- c6x: Fix multilib support -- c6x: Add patch fix internal instruction error (GCC 57295) Signed-off-by: Dan Tejada <dan.tejada@cantada.com>
* | arm: Disable context functions for ThumbChris Packham2020-11-011-0/+1
| | | | | | | | | | | | | | | | | | Similar to commit 57679b5e ("Disable context functions for Thumb") when building for thumb we need to unset UCLIBC_HAS_CONTEXT_FUNCS. Fixes #1397 Signed-off-by: Chris Packham <judge.packham@gmail.com>
* | Merge branch 'xlocale' of git://github.com/lancethepants/crosstool-ng into ↵Chris Packham2020-11-011-1/+0
|\ \ | | | | | | | | | lancethepants-xlocale
| * | Don't remove XLOCALE support unconditionally.lancethepants2020-10-151-1/+0
| | | | | | | | | | | | Signed-off-by: Lance Fredrickson <lancethepants@gmail.com>
* | | binutils: Disable glob for better portabilityAlexey Brodkin2020-10-141-0/+4
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since glibc 2.27 glob interface was changed [1] and so "glob" & "glob64" symbols require glibc 2.27+. For us that means if we build Binutils on a machine with glibc 2.27+ produced binaries won't be any longer usable on machines with older glibc. As an example [2]: build on Ubuntu 18.04 (with glibc 2.27) and try to run on CentOS 7.x (with glibc 2.17), you'll see this: ---------------------->8------------------- ldd ld ld: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by ld) ---------------------->8------------------- Now given glob is not really used by Binutils itself (only needed by GDB) and we build Binutils & GDB separately let's make at least Binutils more portable. In theory we may even try to do the same hack for GDB forcing it to use imported glob implementation. But since GDB is now built strictly by C++ compiler we'll get waaay to many incompatibilities due to multiple changes of C++ ABI in between GCC 7.5 of Ubuntu 18.04 and GCC 4.8.5 of CentOS 7.x, so there's no point to even try. [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=ccf970c7a77e86f4f5ef8ecc5e637114b1c0136a [2] https://github.com/zephyrproject-rtos/sdk-ng/issues/280 Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
* | Merge pull request #1400 from fvalette/fix-m4-build-for-mingw32-hostChris Packham2020-10-071-0/+8
|\ \ | | | | | | m4: fix build for mingw32 host
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-22 00:33:43 +0000