glibc-2.17 and above no longer have external addons or ports.
So if we are => 2.17, don't even think about trying to mess with ports
or addons.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
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>
Glibc actually does create a build executable. It's under sunrpc and it's
called cross-rpcgen. It uses gettext, so if that's not available in a standard
place on your system (for example if you're using Mac OS X and Homebrew), then
you are all out of luck.
Signed-off-by: Lawrence D'Anna <larry@elder-gods.org>
Prirotize http downloads before ftp downloads.
By having http download first, those using proxy will work with the
current download mechnism.
This tells me that that mechnism needs to be updated.
(proxy support and/or kconfig toggles)
closes#3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
glibc versions that don't support --with-pkgversion or --with-bugurl
will cause a harmless:
====================
configure: WARNING: unrecognized options: --with-bugurl...`
====================
If it's set, use it, if it's a recognized option.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As posted on http://www.eglibc.org/
====================
EGLIBC is no longer developed and such goals are now being addressed
directly in GLIBC.
====================
I'm not interested in maintaining build support for unsupported
software.
Older branches of crosstool-ng continue to have eglibc support.
If you find issues with older branches, I'm always open to pull
requests.
Removing eglibc also frees up glibc cleanup and build optimization.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
This change updates the download locations to default to the official
download site.
For gcc and gdb, also separate out the linaro download locations so that
if you are downloading the linaro variant, it skips trying to download
from the official gcc mirror.
This commit closes#3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Do to glibc what we did to eglibc in #dff359adf15c.
Only (very) old versions of glibc have other external addons,
and they are no longer meaningful.
But for consistency, do the change nonetheless.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Don't download glibc-ports when glibc or eglibc version greater than 2.16,
because the "ports" source is mainline in the glibc or eglibc since version 2.17.
Signed-off-by: "Daniel Zimmermann" <netzimme@gmail.com>
Message-Id: <9c045ca3cf1b9dc89da3.1384602843@haus-VirtualBox>
Patchwork-Id: 291766
[yann.morin.1998@free.fr: slightly tweak subject, change variable name]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This patch adds partial support for glibc locales.
For now, it only generates the appropriate locales when the host and the target
have the same endianness and uint32_t alignment.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
The NPTL add-on has always been internal, so there is no
reason to try downloading it, it will never succeed.
Add provision to skip other add-ons as well.
For consistency, do the same test in both glibc and eglibc.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some addons are bundled with glibc/eglibc, so we should not try to
download and extract them.
This is done as thus:
- at download time:
- if the add-on download fails, keep going;
- at extract time:
- if the addon is present in the source tree, ignore it;
- if the addon is missing in the source tree:
- if the archive is present, extract it;
- if the archive is missing, bail out.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
glibc and eglibc have a very similar extraction process, so it
makes sense to commonalise it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Fixes the issue with {e,}glibc addons having short and long names (such as
eglibc-ports-2_13 and ports), which caused configure scripts to run
through them twice and thus configuring incorrectly.
For instance, the mips64el-n32-linux-gnu toolchain would be recognized
correctly first, but then the second pass would change it to mips32,
building a mixed MIPS-III N32 and MIPS-I libc.
Signed-off-by: Nicolás Reynolds <fauno@kiwwwi.com.ar>
[yann.morin.1992@anciens.enib.fr: remove spurious trailing spaces]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Final step at sharing code between glibc and eglibc.
Fall, wall of shame, fall!... :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The reunification of the glibc/eglibc code paths exposed a nasty
bug in the glibc build: use of PARALLELMFLAGS breaks the build.
See the explanations in that bug report against FC6:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=212111
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
glibc and eglibc each have two very similar ways of building this list.
This can, and should definitetly, be shared.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It will be possible to use that also with eglibc, so this hunk belongs to
the common code.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Use the common procedure, shared between glibc and eglibc. This requires
that glibc-specific bits be included in the shared procedure.
But still build the full libc with the glibc-specific procedure. This will
be commonalised in a future commit.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This is an obsolete version which is no longer used by any sample (the only
user, the ia64 sample, has been removed).
It also makes the code path a bit complex, with twists just to accomodate
that version. Removing the version will make those twists go away, and
will ease commonalisation of glibc and eglibc in the future (hopefully!).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
I ran into some minor difficulties looking through the build log for a
particular file: I wasn't interested in seeing it unpacked, but only
when it is built or installed. Adding these two levels allows me to
differentiate between those cases.
[Yann E. MORIN: Those are blind log levels, and are used only to search
in the build-log afterward.]
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
glibc installs some bash-scripts, but uses the path to the buildtool
bash as interpreter (on the shebang line). This is only a symlink to
the real bash, and thus is not available at runtime.
Fix that by assuming that bash on the target *will* be /bin/bash.
We can not rely on the user-provided version string (be it via the
choice, or manually entered), so fallback to reading version.h,
which is both reliable and always present.
It's now been a while that glibc switched to git from cvs.
Get rid of cvs to download glibc; this will make for a good
cleanup before we add git support! :-)
If the selected ARCH is dual-bitness (eg. supports 32- and 64-bit),
then we need to know the correct place where to fetch some headers.
Currently, this applies only to x86 variants: i386 and x86_64.
The option to retrieve snapshots is already handled by
the generic 'specific date' and 'use latest' entries.
No need for a special case, as there's no code for it.
During the conversion to using bash arrays, the glibc build script
was improperly converted, and contains an incorrect variable
assignment to the config_options array.
- recently, tarballs for glibc 2.8 and 2.9 have appeared on the GNU ftp site
- always use a dot in version strings (eg. 2.9, not 2_9)
/trunk/scripts/build/libc/glibc.sh | 135 76 59 0 +++++++++++++++++++++++++-------------------
/trunk/config/libc/glibc.in | 71 45 26 0 +++++++++++++++--------
2 files changed, 121 insertions(+), 85 deletions(-)
