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(-)
The glibc.sh script doesn't handle the glibc versions with
an underscore very well (bash expected integer error). I
have attached a small patch for that. Instead of looking
for "not period" I changed the sense to look for numbers.
I initially tried to make it look for either a period or
an underscore, but that didn't work like I wanted (probably
because I did something wrong).
Original patch modified to be more robust.
/trunk/scripts/build/libc/glibc.sh | 8 4 4 0 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
- renaming the dircetory in CT_ExtratAndPatch is wrong:
- patches against the C library addons may be build against the short *or* long name... :-(
- symlink is more robust, even if less nice
- renaming the directory _after_ CT_ExtractAndPatch is too late:
- if patches are against the short name, and we renamed too the long name, patches don't apply
- so we'll never reach the point where we rename
/trunk/scripts/build/libc/glibc.sh | 1 0 1 0 -
/trunk/scripts/build/libc/eglibc.sh | 1 0 1 0 -
/trunk/scripts/functions | 2 1 1 0 +-
3 files changed, 1 insertion(+), 3 deletions(-)
CT_LIBC_FILE:
- that one was not easy, as it had sneaked into CT_ExtractAndPatch
- which in turn made CT_ExtractAndPatch have references to C library addons
- which in turn relieved the C library _extract functions from doing their own job
- which in turn imposed some nasty tricks in CT_ExtractAndPatch
- which in turn made life easier for the DUMA _get and _extract functions
- which unveiled some bizare behavior for pushd and popd:
- if using smthg ike: 'pushd foo |bar':
- the directory is *neither* changed
- *nor* is it pushed onto the stack
- which made popd fail
CT_MakeAbsolutePath:
- used only to make CT_LOCAL_TARBALLS_DIR canonical
- which is ((almost) useless:
- hopefully, the user entered a full path already
- if it's not the case, too bad...
/trunk/scripts/build/debug/200-duma.sh | 5 1 4 0 +--
/trunk/scripts/build/libc/glibc.sh | 61 32 29 0 +++++++++++++++++---------------
/trunk/scripts/build/libc/uClibc.sh | 16 10 6 0 +++++---
/trunk/scripts/build/libc/eglibc.sh | 48 26 22 0 ++++++++++++++-----------
/trunk/scripts/crosstool.sh | 8 0 8 0 ----
/trunk/scripts/functions | 77 15 62 0 ++++++++--------------------------------
6 files changed, 84 insertions(+), 131 deletions(-)
They are nonetheless in sync and need not be regenerated.
Fix that by touching the files to have 'make' believe they are up-to-date (which they are).
/trunk/scripts/build/libc/glibc.sh | 5 5 0 0 +++++
/trunk/scripts/build/libc/eglibc.sh | 7 6 1 0 ++++++-
2 files changed, 11 insertions(+), 1 deletion(-)
It dates from dawn ages of the original crosstool code, and is not well explained. At that time, binutils might not understand the sysroot stuff, and it was necessary to remove absolute paths in that case.
/trunk/scripts/build/libc/glibc.sh | 14 2 12 0 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
