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>
It is used for skipping unnecessary compilation steps when the libc
doesn't need to be compiled (eg. when we do not use a C library).
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <150eadb0117e697d79aa.1353625025@blackmint>
Patchwork-Id: 201222
Replace the 32-bit-only mingw32 with mingw-w64 that is capable
of building toolchains for both 32-bit and 64-bit Windows.
kernel/mingw: replace mingw32 with generic Windows
kernel/windows: New windows kernel supporting 32 and 64 bit arch
libc/mingw: Remove old options
patches: Remove old mingw libc options' patches
Signed-off-by: "Yann Diorcet" <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: array var in libc/mingw.sh, typos]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <b045ac08fc9eac2e5ee3.1352898499@blackmint>
Patchwork-Id: 198901
The latest kconfig stuff is more stringent when it comes to validating
the dependency of the symbols. It is no longer possible to have a symbol
depend on itself (such as our construct for arch/cc/libc/... was doing).
Fix our generated-file infrastructure to avoid these situations when the
new kconfig stuff will be merged (in a following changeset).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In fact, it is only supported in a few legacy versions.
Keep LT available for all eglibc versions, although it might need
a similar safeguard...
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>
Add the option to build a cross-compiler for kernel type 'mingw'.
The resulting cross-compiler can be used to build applications on a Linux host
that can be run on a Windows target.
Compiler is build using the mingwrt and w32-api packages aviable from the
MinGW project (http://sourceforge.net/projects/mingw).
The windows headers (w32-api package) are extracting with the kernel_headers
step The libraries and other headers from both packages are build and
installed in the various steps of libc
Signed-off-by: Bart vdr Meulen <bartvdrmeulen@gmail.com>
[yann.morin.1998@anciens.enib.fr: fix kernel headers comment, don't "return 0"]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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! :-)
Woo... It seems the glibc guys finally decided that tarballs
were not deprecated, in fact.
The patchset was vampirised from Gentoo (kudos, guys!), and
applies to glibc+ports, so that's why it's been added as a
patchset against ports, not against glibc.
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.
- 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(-)
