On 64bit MacOS `gcc -dumpmachine` gives i686 for the host machine.
This conflicts with the expectations of some following configure scripts
that a 64bit x86 is given as x86_64; i686 is understood as a 32 bit machine.
config.guess sets the host machine in CT_BUILD correctly.
yann.morin.1998@anciens.enib.fr:
As suggested by Khem RAJ on the ML, always use config.guess.
Call to get the directory mode depending on $CT_SYS_OS
yann.morin.1998@anciens.enib.fr:
CT_SYS_OS has changed on Linuxsystem, it only gets the kernel name "Linux",
and not the system name, 'GNU/'.
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.
On non-GNU systems (BSD/MacOS) there is no uname -o.
Suppress the failure message on these systems in the
call to set CT_SYS_OS (uname -s actually sets this variable).
yann.morin.1998@anciens.enib.fr: remove 'uname -o' altogether.
g++ is only needed when building additonal libs on the HOST,
so check wheter g++ is available for the HOST compiler only
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[Yann E. MORIN: fix space damage]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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
Saving and restoring the steps requires saving/restoring multiple
directories. Depending on the configuration, some may not exist.
Add a wrapper that checks before creating/extracting the tarballs.
Disable unaligned access at least for mcpu32, m68010 and m68020.
These processors certainly do not like unaligned accesses.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
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>
When building a baremetal cross compiler I want to be able to select
the elf format and not be forced to build the elf2flt package.
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[Yann E. MORIN: tweak the commit message]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
