summaryrefslogtreecommitdiff
path: root/scripts/build/libc/avr-libc.sh
AgeCommit message (Collapse)AuthorFilesLines
2017-01-25Run all configure scripts using ${CONFIG_SHELL}Alexey Neyman1-0/+1
... as its help message says in menuconfig. Signed-off-by: Alexey Neyman <stilor@att.net>
2016-12-02Fix use of custom location if it is a directory.Alexey Neyman1-1/+1
In that case, CT_GetCustom just creates a symlink to the original. In that case, 'cp -a <path> .' gives an error and 'cp -a <path> <newdir>' creates <newdir> as a symlink (which will then run the build inside the shared directory, .build/src/<package>). Signed-off-by: Alexey Neyman <stilor@att.net>
2016-11-21Partially revert 6f8e89cb5ca061e899bf3feaaf3fecf30d366c3e.Alexey Neyman1-2/+2
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-08-23libc/*.sh: Deprecate libc_check_config step.Alexey Neyman1-4/+0
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>
2015-12-08scripts: Update usage of CT_GetCustomBryan Hundven1-12/+2
This commit updates the build scripts to match the new usage of CT_GetCustom from the previous change. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-11-17consistency: Use exported variables of required toolsBryan Hundven1-2/+2
We check for apps: * make * sed * grep * awk * libtool/libtoolize * install * patch * and more ...during configure. Our scripts should be consistent about using the variables that define where the found tool was found. Of course, we do hard-link these tools in buildtools, but that should be a backup for the components we are building. Our scripts should always use the tools we find. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
2015-06-21avr-libc: add support for avr-libc C libraryErico Nunes1-0/+71
This commit adds support for the avr-libc C library. According to the project page at http://www.nongnu.org/avr-libc , the avr-libc package provides a subset of the standard C library for Atmel AVR 8-bit RISC microcontrollers. In addition, the library provides the basic startup code needed by most applications. Support for this library in crosstool-ng is only enabled for the AVR 8-bit target. The avr-libc manual and most distributions build the AVR 8-bit gcc toolchain with the "avr" (non-canonical) target. Some experimentation also led to the conclusion that other (canonical) targets are not very well supported, so we force the "avr" target for crosstool-ng as well. The manual also recommends building avr-libc after the final gcc build. To accomplish this with crosstool-ng, a new do_libc_post_cc step is added, in which currently only avr-libc performs its build, and is a no-op for the other libc options. Signed-off-by: Erico Nunes <nunes.erico@gmail.com>