libgomp is the GNU implementation of the OpenMP API.
It can be usefull to have or miss, depends...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Force gcc to not link with some companion libraries when
there are not needed (because selected-out).
There is no option to tell gcc *not* to build the Graphite and/or
LTO stuff. They *will* be built if gcc finds the suitable companion
libraries. If we do not provide them, but the host has them, then
gcc *will* find them, and link with them.
Consider the following:
- host has suitable PPL and CLooG (eg. Debian Squeeze)
- user wants to build gcc>=4.4
- user de-selects GRAPHITE
- gcc will find the hosts PPL and CLooG, and will use them
- the user moves the toolchain to an older host that does
not have them (eg. Debian Lenny)
- the toolchain fails, when it was properly setup not to
So, explicitly tell gcc *not* to use unneeded companion libs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
While GMP and MPFR are required by gcc>=4.3 (to build the frontends),
and MPC is required by gcc>=4.5, the other libs are not. If they are
present then gcc will enable advanced features; if they are missing,
then gcc will (should) simply disable those features.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Use the MIPS ABI selection to properly munge the uClibc config file.
This has the side effect to force the ISA:
- n32 ABI -> MIPS-III ISA
- n64 ABI -> MIPS64 ISA
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This adds selection for one of the o32, n32 and n64 ABIs.
Later, we can easily use those boolean options, rather than
relying on a user-supplied string option.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The symlinks are needed only during the build process.
The final gcc will still search those dirs, but will also search
the standard lib/ dirs, so we can get rid of the symlinks.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
For now, ncurses is the only dependable target library built for gdb.
But expat is coming, and there's no reason to install each library in
its own place.
So, install ncurses in a generic directory, where other dependable
libraries can be installed as well.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
As there's no longer any user of the companion libraries on the
target, nuke the build for the target.
Well, at least, there's libelf that's still needed by ltrace, so
we keep it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Although the gdb ./configure advertises for GMP and MPFR, those libraries
are not used by gdb (the ./configure is used across different packages,
hence the check for GMP/MPFR). See:
http://sourceware.org/ml/crossgcc/2010-08/msg00168.html
The same applies to MPC.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When targeting mingw32, gcc expects to find its include files
in "mingw/include" instead of the traditional "usr/include".
[Yann E. MORIN: split the original patch]
On some Fedora boxen (at least FC13), it is also required
to link with libm when static ppl is used.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To reduce filesizes of the toolchain and even improve build times
of projects to be build with this toolchain it is usefull to strip
the delivered toolchain executables. Since it is not likely that we
will debug the toolchain executables itself we do not need the
debug information inside the executables itself.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
For some scenarii, libmudflap is not very usefull
or can break the build. Make in an optioon that
defaults to 'N' to be on the safe side.
For the core gcc-s, there is absolutely no need
to build libmidflap.
Idea from: Bernhard Pfund <bernhard@chapter7.ch>
Some time, someone updated the locale Makefile to use
newer pre-generated locales data, but did not upload
those.
So we just force using the existing, ageing archive,
dating back 20030818. Sigh...
It seems that using pre-generated locale data can be more problematic
than usefull in some circumstances.
Offer a config knob to enable/disable use of the pregen locale data.
Also, do not extract pregen locales data ourselves, it's broken.
I was unable to make the cross-ldd from uClibc to work, and
it is not possible to build it on non-POSIX system.
Besides, we have a generic script that is in the starting-blocks
to replace it, that will work for any C library, and also will
work on non-POSIX systems. Bonus!
When building a cross-compiler for a target which uses a file extension for
binaries the symbolic link to cc is not created correctly because the lookup
of the gcc binary is done in a incorrect path
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
GDB requires PDcurses instead of ncurses while running on Windows.
So, do not always compile ncurses in case GDB needs to build.
PDcurses is provided by an earlier build step and is not described in
this file.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
[yann.morin.1998@anciense.nib.fr: we already have a way to detect ncurses usage]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add several development libraries to the build of the mingw cross-compiler
to be used on target
Libraries:
PDCurses (port of the ncurses library)
GnuRX (the regex library)
DirectX
OpenGL
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[yann.morin.1998@anciens.enib.fr: don't show DX and RX versions if disabled]
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>
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.
Accept a local tarball name as the source of the Linux kernel headers,
rather than forcing the user to use either an upstream tarball, or a
local pre-installed headers tree.
Here, we implement a highly ugly hack. I'm not proud of that one...
To build the libstdc++ library, the compiler requires the C library. In
case we build for non-baremetal, this is normally handled by the final
step, later.
But in the case of bare-metal, we never go through the final step (because
it does not work, and it seems complex enough to make it work), so the
baremetal compilers are issued out of the core step.
A few facts:
- building the C library requires a proper core compiler
- core compiler is issued from one of the core passes
- the C library is required to build libstdc++
- newlib is only built for baremetal
- in bare metal, the final compiler is issued from one of the core passes
So we need to build the C library between core pass 1 and core pass 2.
The only place is eithe libc_headers() or libc_start_files(). The most
pertinent seems to be libc_start_files().
So we build newlib from libc_start_files(), and leave libc() empty.
static linking is not possible on MacOS, and unnessecary on other systems.
The old optimization and warning flags crash the gcc on MacOS
and (imho) are a bit overdone for this software.
This patch adds support for installing the gcc test suite. A helper
Makefile is provided for building and running the gcc tests.
The default configuration runs all gcc tests and requires automatic
ssh/scp login access to a networked target board. See README for
more details.
Note: Current feature is tested with the powerpc-unknown-linux-gnu
sample but it should work with others as well.
Signed-off-by: Martin Lund <mgl@doredevelopment.dk>
The shell wrapper script uses a nonportable call to readlink.
Thus, always use the binary wrapper under BSD/MacOS.
yann.morin.1998@anciens.enib.fr:
Use 'case' instead of 'if'.
The call to stat to find out if a file is a symlink works only on GNU systems,
and the replacing portable call to readlink is also shorter and more concise code.
yann.morin.1998@anciens.enib.fr:
Apply simpler test, after discussion with author and Arnaud LACOMBE on the ML.
While compiling a canadian toolchain for host=mingw32, build=linux,
target=m68k-elf the build fails because in this step of the gcc build
the Host compiler is used in this stage with the build-flags for the
build system. This results in an error where the header <sys/wait.h>
cannot be found.
This problem happens at least in the GCC-4.3.x and GCC-4.4.x range.
This is solved by passing the proper compilers on the Make cmd-line
Signed-off-by: Remy Bohmer <linux@bohmer.net>
Previous addition of the canadian cross compiler did not allow
to build a baremetal only variant, no reason why this is not
allowed
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
When building a cross-compiler for a host which depends
on file extensions the symlink for cc was not installed correctly
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[Yann E. MORIN: style fixes, enhancements, code prettying]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Insight seems to be very slow to follow up on mainstreram gdb.
Latest snapshots are more than 6 months old.
Moreover, I don't have time to maintain insight support in crosstool-NG;
and, because I don't use it, I am unable to find any breakage.
For uClibc, the name of the Blackfin architecture is 'bfin'. Actually,
the naming of the architecture is quite messy: for toolchain tuples
and uClibc, it's bfin, but for the kernel, it's blackfin. We've
arbitraly choosen to name it "blackfin" in Crosstool-NG.
Add Blackfin-related uClibc patch to fix a build failure related to
fork() being used in unistd/daemon.c.
Yann E. MORIN:
Apply the patch to the kernel/linux build script to use 'linux'
in the noMMU tuples. See:
http://sourceware.org/ml/crossgcc/2010-04/msg00010.html
When building for bare-metal the core-gcc compiler is delivered
as final compiler, so the version info and bugurl is useful
in the core compiler as well.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
In some exotic case the autoreconf step of mpfr is not executed (correctly)
leaving an incorrect version number for libtool in the configure script.
After extracting the sources files, force autoreconf to be executed.
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
If threads are disabled in libc, we don't want to enable them in the
final compiler. Doing so pass the configure stage, but fails latter on
a missing <pthread.h>.
Moreover, we don't want to build libgomp if threads are disabled; its
configure script would fails anyway.
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
sstrip is now alone in its 'tools' menu, and we will probably never gain
any other 'tool'. Besides, sstrip is just strip, but a little bit more
agressive, so it deserves going to the 'binary utilities' menu.
The native 'tic' will _always_ be run on the build
machine, so no need to handle canadian/native/...
Reported by: Trevor Woerner
http://sourceware.org/ml/crossgcc/2010-03/msg00055.html
(transplanted from 26e89d367ea11660fd3a0bf0bcad8763e4fa21cf)
ltrace uses i386 and x86_64, whereas crosstool-NG use x86 for both cases.
Fix that by detecting what bitness we're building for, and pass appropriate
i386 or x86_64 to ltrace's configure.
The companion libraries on the target are required only for internal use by
binutils and gdb. The user should not have to know about this, so hide the
option.
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! :-)
Signed-off-by: Remy Bohmer <linux@bohmer.net>
[yann.morin.1998@anciens.enib.fr: use defaults for CT_TARGET_ARCH]
Signed-off-by: "Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
We only build the static ncurses, to be used to build the native gdb,
and it needs not be available for anyone but us. So install it into
a temporary place, and get rid of it once gdb is built.
Initial version of adding autoconf as a companion tool.
Signed-off-by: Richard Strand <richard.strand@icomera.com>
[yann.morin.1998@anciens.enib.fr: use generic overide tools dir]
[yann.morin.1998@anciens.enib.fr: update menu entries]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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.
Trying to download every extension in turn does not work.
The Debian server returns a friendly 404-page that is
saved as the orig.tar.bz2 file. Help the helper by giving
it the extension to retrieve.
From this version of ltrace the maintainer has removed support for
GNU Autotools, so the patch sets needed to be reworked.
Included is the latest Debian patch, by the Debian ltrace maintainer
Juan Cespedes <cespedes@debian.org>, the OpenEmbedded patches for cross
compiling, by Khem Raj <raj.khem@gmail.com> and a further set of patches
by Joachim Nilsson <jocke@vmlinux.org> for crosstool-NG.
Using this: tar cf - -C "/some/place" |tar xf - -C "/some/other/place"
to copy a directory to another place does not properly fail (when it does).
Using this instead: cp -av "/some/place" "/some/other/place"
makes it easy to see why and how it failed.
Impacted:
libc/uClibc
debug/ltrace
tools/sstrip
scripts/populate
Don't select unneeded config knobs. Don't select non-existing config knobs.
Use the "no patch" config knob, instead of pointing to an non-exiting local
patch dir. Simplify the tuple-related scripts. Update the samples.
Add config option to build wtarget code with THUMB interworking.
This is used to build the C library as well as all other code
that runs on the target.
The newlib "team" rolls new releases about once a year (december).
This is quite a long time between releases, in case code was fixed.
So, allow user to use a CVS snapshot to benefit early from fixes
and enhancements to newlib.
newlib handles the build/host/target a bit differently as one would expect:
build : not used
host : the nachine that builds newlib
target : the machine on which newlib will run
ncurses is built solely for the sake of building a native gdb.
The user should not rely on this library to build his/her userland,
but should rather build his/her own. So we remove it from the
sysroot after we successfully build the native gdb.
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.
For CLooG/PPL 0.15.3, the directory name was simply cloog-ppl.
For any later versions, the driectory name does have the version, such as
cloog-ppl-0.15.4.
For CLooG/PPL 0.15.3, the directory name was simply cloog-ppl.
For any later versions, the driectory name does have the version, such as
cloog-ppl-0.15.4.
Add the WRAPPER_NEEDED silent config option, that can be selected by
components that require it (companion libs so far).
Rely on this config option when deciding to install the wrapper,
instead of checking GMP/MPFR or PPL/CLoog/MPC.
Downoading a non-existing file from sourceforge gives you a "200 OK"
and an index.html. As we try to retrieve a .tar.bz2 first, and duma
is bundled in a .tar.gz, we won't get appropriate content, so
just force the extension to avoid the problem.
Thanks to Ingmar Schraub <is@eseco.de> for pointing out the issue.
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.
For every components where it makes sense, use bash arrays (instead
of a string with space-separated values) to store the options pased
to ./configure.
Rewrite part of the code to better match the rest.
Most notably, rewrite handling of:
if [ ... ] && [ ... ]
to:
if [ ... -a ... ]
This has the positive side effect of calling "[" only once, although
"[" is probably a shell built-in.
To test for existing files, use "[ -f blabla ]", not "[ -a blabla ]"
Checking for a file exsitence with "-a" is a bashism.
Althoug we _are_ using bash, it's disturbing as it can be misread as
the 'and' operator. Fix by using "-f".
The tmul test uses a compiled-in input file in $(srcdir).
The problem is that the Makefile passes it unquoted. The C code
tries to stringify it using clever macros, which may *usually* work.
In my case the source directory was named:
.../toolchain-powerpc-e500v2-linux-gnuspe-1.0-2.fc10/.../tests
And guess what? During testing I found out the program fails because
it tries to open:
.../toolchain-powerpc-e500v2-1-gnuspe-1.0-2.fc10/.../tests
Yes, CPP tokenized the macro before stringifying it and not surprisingly
the 'linux' part was converted to 1.
[on Fedora-10: cpp (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)]
So the attached patch simplify the macros and pass the path as string
from the Makefile.
Add implementation for a candadian build option already
present in crosstool in order to build a cross-compiler
where build != host != target
Signed-off-by: Bart van der Meulen <bartvdrmeulen@gmail.com>
Collect the build tools in a seperate folder in order to prevent accidental
calling our newly build tools.
Signed-off-by: Bart van der Meulen <bartvdrmeulen@gmail.com>
Once we have canadian in place, Mingw32 can be a legitimate host,
so we have to recognise that along with Cygwin.
Also fix recognising Cygwin hosts.
Signed-off-by: Bart van der Meulen <bartvdrmeulen@gmail.com>
They have nothing to do in here, just let the user
configure his/her system appropriately.
-------- diffstat follows --------
/trunk/scripts/build/libc/eglibc.sh | 1 0 1 0 -
/trunk/scripts/functions | 100 0 100 0 -----------------------------
/trunk/config/global/download.in | 148 0 148 0 -------------------------------------------
3 files changed, 249 deletions(-)
- introduce the config dir, where components can store their config files
- move the munged uClibc config file to the config dir
- now, the state dir really is an indication that a build can be restarted
Thanks to Groleo Marius <groleo@gmail.com> for spotting the inconsistency
of the state dir usage, and suggesting this change.
/trunk/scripts/build/libc/uClibc.sh | 6 3 3 0 +++---
/trunk/scripts/crosstool-NG.sh.in | 9 7 2 0 +++++++--
/trunk/scripts/functions | 15 12 3 0 ++++++++++++---
3 files changed, 22 insertions(+), 8 deletions(-)
Initial patch by Dmitry PLOTNIKOV: http://sourceware.org/ml/crossgcc/2009-03/msg00053.html
It [the toolchain] uses current ct-ng (nightly snapshot 20090324, latest
release 1.3.2 work also), glibc 2.9 (from CVS), binutils 2.19 and latest
snapshot of GCC 4.4.0 (as of March 20, 2009).
We have successfully built linux kernel 2.6.29 and a lot of other stuff
with this toolchain.
Here's the patch that adds GCC 4.4.0 to the ct-ng menu and enables it to
download a 4.4.0 snapshot from ftp.
Patch was adpated by me, mostly to better fit the configuration layout.
/trunk/scripts/build/cc/gcc.sh | 34 22 12 0 ++++++++++++++++++++++------------
/trunk/config/cc/gcc.in | 35 30 5 0 ++++++++++++++++++++++++++++++-----
2 files changed, 52 insertions(+), 17 deletions(-)
- find the executables extension (needed under some OS, like Winblows)
- build tic in //
- simplify the make and install command lines
/trunk/scripts/build/debug/300-gdb.sh | 10 7 3 0 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
Seems ncurses 5.7 need build host stage for tic step; if use host tic
(ubuntu) the build process hang in the below step.
So I guess need to build ncurses host stage to build new tic
and provided a patch to that efect.
And in fact, we do need "tic" to run on the _build_ system to properly
generate the terminfo database.
Note: this is fully functional, but still requires a litle bit of
tweaking so that ${CT_BUILD}-gcc gets used instead of plain gcc.
But that's a minor problem for now...
/trunk/scripts/build/debug/300-gdb.sh | 35 33 2 0 +++++++++++++++++++++++++++++++++--
/trunk/scripts/build/internals.sh | 1 1 0 0 +
2 files changed, 34 insertions(+), 2 deletions(-)
- 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(-)
On 20090115.0012+0100, "Andy Johnson" <ajohnson@aecno.com> wrote:
ltrace wouldn't build on PowerPC because in the
sysdeps/linux-gnu directory in the ltrace source tree
the powerpc directory is called ppc. I added some code
in 400-ltrace.sh to create a symlink for it so it will
build now.
Patch slightly modified by me before applying.
/trunk/scripts/build/debug/400-ltrace.sh | 5 5 0 0 +++++
1 file changed, 5 insertions(+)
Andy JOHNSON wrote:
The Java compiler for GCC versions 4.3.0 and up requires the
Eclipse compiler "ecj1" to be built as well. I added "gcj" to
the list of utilities to make the initial link.
/trunk/scripts/build/cc/gcc.sh | 12 12 0 0 ++++++++++++
/trunk/scripts/crosstool.sh | 2 1 1 0 +-
/trunk/config/cc/gcc.in | 6 6 0 0 ++++++
3 files changed, 19 insertions(+), 1 deletion(-)
- DUMA separates its name from its version with an underscore, not with a dash.
/trunk/scripts/build/debug/200-duma.sh | 3 2 1 0 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
- 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(-)
- this is not really used yet, as only the iberty and bfd libraries are built
- if we ever are to build the full binutils for the target, then it is already configured to use the target GMP and MPFR.
/trunk/scripts/build/binutils.sh | 7 7 0 0 +++++++
1 file changed, 7 insertions(+)
Original patch by Thomas PETAZZONI, with soe improvement by myself.
/trunk/scripts/build/libc/uClibc.sh | 10 9 1 0 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
We need GNU Awk? Then check for, and use 'gawk', not plain 'awk'.
Be a little mre verbose if a tool was not found.
/trunk/configure | 7 4 3 0 ++++---
/trunk/scripts/build/kernel/linux.sh | 2 1 1 0 +-
/trunk/scripts/functions | 16 8 8 0 ++++++++--------
/trunk/scripts/saveSample.sh | 4 2 2 0 ++--
4 files changed, 15 insertions(+), 14 deletions(-)
This helps those who want to relocate their toolchains later.
Reported by Nye Liu: http://sourceware.org/ml/crossgcc/2008-10/msg00093.html
/trunk/scripts/build/cc/gcc.sh | 2 1 1 0 +-
1 file changed, 1 insertion(+), 1 deletion(-)
- copy sources to build directory, as it does not build out-of-tree
- add a patch to make it build for non *-linux-gnu host tuples
- add a patch to make it cross-build correctly
/trunk/patches/ltrace/0.4/100-fix-build-with-exotic-linux-host-OS.patch | 26 26 0 0 +++
/trunk/patches/ltrace/0.4/110-allow-cross-compile.patch | 89 89 0 0 ++++++++++
/trunk/scripts/build/debug/400-ltrace.sh | 5 3 2 0 +
3 files changed, 118 insertions(+), 2 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(-)
- change the menu label from 'Target OS' to 'Operating System',
- bare-metal is a kind of kernel (OS), rename to 'bare-metal' from 'none',
- update the kconfig.mk to generate the kernel choice entries,
- update glibc&eglibc kernel version option accordingly.
Update the debug & tools confiog file generation to match with arch & kernel.
Print terse command lines when building in kconfig/ (a-la Linux kernel).
Fix the makefile rules in kconfig/kconfig.mk to be /simple/ rules.
/trunk/kconfig/kconfig.mk | 117 81 36 0 +++++++++++++++++++++----------
/trunk/config/kernel/linux.in | 4 4 0 0 +
/trunk/config/kernel/bare-metal.experimental.in | 15 15 0 0 ++++
/trunk/config/kernel.in | 33 5 28 0 +--------
/trunk/config/libc/glibc-eglibc-common.in | 4 2 2 0
5 files changed, 107 insertions(+), 66 deletions(-)
This is needed for some architectures to compile the Java frontend (eg. ARM with uClibc).
/trunk/config/cc/gcc.in | 41 39 2 0 +++++++++++++++++++++++++++++++++++++++--
/trunk/scripts/build/cc_gcc.sh | 8 5 3 0 +++++---
2 files changed, 44 insertions(+), 5 deletions(-)
PowerPC unveiled that you can't reliably build a target libgcc until you have C library headers.
In fact you can't build it at all. The fact that it did build for some architectures was purely coincidental, and a mistake.
This fix should still allow to build uClibc-based toolchains (some ARM uClibc toolchains were build-tested).
/trunk/scripts/build/cc_gcc.sh | 100 47 53 0 +++++++++++++++++++++++-------------------------
1 file changed, 47 insertions(+), 53 deletions(-)
On some distros (eg. Fedora), the native objdump can not interpret objects not for the native system, and thus fail.
This commit adds a new patch against glibc-2.7 that introduces OBJDUMP_FOR_HOST, wich, if set, overides the detected objdump.
Note: bizarely enough, glibc already has code to detect the cross-objdump, but that does not work for an unknown reason... :-(
/trunk/patches/glibc/2.7/220-objdump_for_host.patch | 13 13 0 0 +++++++++
/trunk/scripts/build/libc_glibc.sh | 37 21 16 0 +++++++++++++++------------
2 files changed, 34 insertions(+), 16 deletions(-)
- symlink all lib64/ dirs to the corresponding lib/ dir
Also, prevent gcc from installing some of its target libs outside of the sys-root, in the first place.
Thanks to Laurent DUFRECHOU for reporting the bug and testing the fix.
/trunk/scripts/build/cc_gcc.sh | 26 0 26 0 --------------------------
/trunk/scripts/crosstool.sh | 14 14 0 0 ++++++++++++++
2 files changed, 14 insertions(+), 26 deletions(-)
Thanks to both Ioannis E. VENETIS and Thomas JOURDAN for their help.
/trunk/scripts/build/cc_gcc.sh | 26 22 4 0 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
Move the check for 'lynx' to where it is needed (that is when sstrip from buildroot is selected).
/trunk/scripts/build/tools/200-sstrip.sh | 1 1 0 0 +
/trunk/scripts/crosstool.sh | 5 0 5 0 -----
2 files changed, 1 insertion(+), 5 deletions(-)
Turned out that none could use GMP and MPFR as the config option changed its name, but the change was not propagated to all users.
/trunk/scripts/build/binutils.sh | 2 1 1 0 +-
/trunk/scripts/build/debug/300-gdb.sh | 2 1 1 0 +-
/trunk/scripts/build/cc_gcc.sh | 6 3 3 0 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
Get rid of this by using printf(1) with no trailing new-line (\n).
Again, thanks to Martin GUY, who pointed this issue.
/trunk/kconfig/kconfig.mk | 2 1 1 0
/trunk/scripts/build/libc_uClibc.sh | 4 3 1 0 ++
/trunk/scripts/showSamples.sh | 78 39 39 0 +++++++++++++++++++++---------------------
3 files changed, 43 insertions(+), 41 deletions(-)
add a config knob to configure the native gdb to use or not to use GMP and
MPFR; _this_config_knob_ will force building the target GMP and MPFR only if
turned on.
/trunk/scripts/build/debug/300-gdb.sh | 2 1 1 0 +-
/trunk/config/debug/gdb.in | 21 19 2 0 +++++++++++++++++++--
2 files changed, 20 insertions(+), 3 deletions(-)
- some (presumably 'old') versions have libduma.so.0.0, while others (presumably 'newer') have libduma.so.0.0.0
- don't build the libraries multiple times, do it in one pass
- install a custom LD_PRELOAD wrapper
/trunk/scripts/build/debug/200-duma.sh | 54 33 21 0 +++++++++++++++++++++++++++++++++---------------------
1 file changed, 33 insertions(+), 21 deletions(-)
Some (most) of the sites we use toretrieve tarballs have http equivallent for the ftp service. Use http as a failover.
There's no solution for those sites that do not have such an http equivalent.
/trunk/scripts/build/binutils.sh | 5 2 3 0 ++---
/trunk/scripts/build/libc_glibc.sh | 4 2 2 0 ++--
/trunk/scripts/build/libc_uClibc.sh | 2 1 1 0 +-
/trunk/scripts/build/debug/400-ltrace.sh | 2 1 1 0 +-
/trunk/scripts/build/debug/300-gdb.sh | 8 3 5 0 +++-----
/trunk/scripts/build/kernel_linux.sh | 7 2 5 0 ++-----
/trunk/scripts/build/cc_gcc.sh | 6 2 4 0 ++----
/trunk/scripts/build/gmp.sh | 4 1 3 0 +---
8 files changed, 14 insertions(+), 24 deletions(-)
Rationale:
Most of the time, soft-float problems are caused by this sucker of gcc:
it has support for soft float for all of the targets I've tried so far,
but does not activate this code until you dwelve into half a dozen of
files to make it accept to build and link the support code...
So, yes: gcc has soft-float support. And again, yes: gcc is a sucker.
- when not compiling NPTL, the shared core C compiler does not exist,
- PATH arranges for the shared core C compiler to be found before the static one, so no need to force it.
- associated patch set
- update the munging function to accomodate the new config variables
libfloat version was missing from the previous commit... :-(
Better handle the case where the sample directory already exist but isn't under revision control, and in case the destination file doesn't exist in the sample directory.
Add a uClibc-0.9.29 patch directory with one patch (from me!).
Update the armeb-unknown-linux-uclibc sample to uClibc-0.9.29.
Some eyecandy in the gdb build process.
- add a framework to easily add new ones
- add gdb as a first debug facility
- add patches for gdb
After the kernel checked its installed headers, clean up the mess of .checked.* files.
Reorder scripts/crosstool.sh:
- dump the configuration early
- renice early
- get info about build system early, when setting up the environment
- when in cross or native, the host tools are those of the build system, and only in this case
- elapsed time calculations moved to scripts/functions
Remove handling of the color: it's gone once and for all.
Update tools/addToolVersion.sh:
- handle debug facilities
- commonalise some code
- remove dead tools (cygwin, tcc)
Point to my address for bug reports.
- use ports addon even when installing headers,
- use optimisation (-O) when installing headers, to avoid unnecessary warnings (thanks Robert P. J. DAY for pointing this out!),
- lowest kernel version to use is only X.Y.Z, not X.Y.Z.T,
- a bit of preparations for NPTL (RSN I hope),
- fix fixing the linker scripts (changing the backup file is kind of useless and stupid);
Shut uClibc finish step: there really is nothing to do;
Add a patch for glibc-2.3.6 weak aliases handling on some archs (ARM and ALPHA at least);
Did not catch the make errors: fixed the pattern matching in scripts/functions;
Introduce a new log level, ALL:
- send components' build messages there,
- DEBUG log level is destined only for crosstool-NG debug messages,
- migrate sub-actions to use appropriate log levels;
Update the armeb-unknown-linux-gnu sample:
- it builds!
- uses gcc-4.0.4 and glibc-2.3.6,
- updated to latest config options set.
Although we no longer need the kernel config file, we now need to specify the kernel source directory when installing headers.
Re-order components downloading to match build order.
Fix the saveSample.sh script in case the referenced files are the same as the destination files.
- reorder most of the environment setup,
- geting, extracting and patching are now components' sub-actions,
- save the current config as a sample to be used as a pre-configured target.
You might just say: 'Yeah! crosstool-NG's got its own repo!".
Unfortunately, that's because the previous repo got damaged beyond repair and I had no backup.
That means I'm putting backups in place in the afternoon.
That also means we've lost history... :-(
