aboutsummaryrefslogtreecommitdiff
path: root/config/libc/avr-libc.in
Commit message (Collapse)AuthorAgeFilesLines
* Add config flags for omitting 'arch' and 'vendor'Alexey Neyman2018-12-101-0/+4
| | | | | | | | ... parts of the config tuple. While here, remove parts that are setting portions of the target tuple to a value that's already the default. Signed-off-by: Alexey Neyman <stilor@att.net>
* Add moxiebox as a choice for libcAlexey Neyman2018-12-011-1/+1
| | | | | | | | | | | | | | | | | This required some rework of the libc selection, as moxiebox is a layer on top of another libc - newlib. Also, moxiebox'es host VM (`sandbox`) needs a libcrypto on the host. We will not have it if we're cross-compiling a canadian cross. Fortunately, all moxiebox needs from libcrypto is SHA256, and it already includes a standalone implementation of SHA256 in its runtime. Provide a little wrapper that allows moxiebox use that implementation for the host binary, too. Also, automate collecting/printing the list of all packages in a given category (e.g. LIBC or COMP_TOOLS), generate a list of all Kconfig symbols for a given category. Signed-off-by: Alexey Neyman <stilor@att.net>
* Make comp.libs use generated templates, tooAlexey Neyman2017-11-291-2/+0
| | | | | | | | This allows us to include the component-to-package relation in the generated kconfig files and make use of that information in the show-config.sh script. Signed-off-by: Alexey Neyman <stilor@att.net>
* Also upgrade non-generated config filesAlexey Neyman2017-07-081-1/+1
| | | | Signed-off-by: Alexey Neyman <stilor@att.net>
* Switch gen-kconfig to new frameworkAlexey Neyman2017-07-081-0/+7
| | | | | | | | | | | | | | | Also: - Move companion_* to comp_* to match the kconfig symbols - Replace bootstrap with former gen-versions.sh - Fold *.in.2 into their respective first parts; this moves common options to the end - if it is undesirable, inclusion of *.in can be moved where *.in.2 used to be (but that will also move version selection after common options). - Retire addToolVersion.sh (may later replace with a more comprehensive script that tries to download the added tarballs, copy the patches and try to apply them, and create a version.desc). Signed-off-by: Alexey Neyman <stilor@att.net>
* Convert the rest of packages to new frameworkAlexey Neyman2017-07-081-63/+1
| | | | Signed-off-by: Alexey Neyman <stilor@att.net>
* avr-libc: update to 2.0.0Erico Nunes2016-04-191-0/+5
| | | | | | | | | | | | | The avr-libc project has released version 2.0.0: http://savannah.nongnu.org/forum/forum.php?forum_id=8460 Apart from changes and bugfixes, this release adds support for gcc 5, which allows us to build gcc 5 avr toolchains and also to update our avr sample. avr-libc 2.0.0 has been build tested both with gcc 4.9.3 and gcc 5.3.0. Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
* config: Update kconfig for new CT_GetCustomBryan Hundven2015-12-081-18/+36
| | | | | | | This commit sort of unifies the kconfigs to handle custom files and directories. Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
* avr-libc: add support for avr-libc C libraryErico Nunes2015-06-211-0/+51
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>