In case we build the C++ compiler, we have to tell gcc where to put the C++
headers, or else it will try to # put it in prefix/tuple/include, which we
make a symlink to sysroot/usr/include during the build, and that we delete
(the symlink!) after the build, but gcc will not look in sysroot/usr/inlcude
for C++ headers by default.
Implements a fix suggested by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: Anthony Foiani <anthony.foiani@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from a0924619112015bdaa81a0a2313d21ef38607bc2)
It happens from time to time that the server mis-behaves, and breaks the
connection right in the middle of nowhere, for no good reason, leaving us
with a partial file, on which the extract pass would choke.
Remove partial downloads, to fail early.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
(transplanted from eefacabd9e72f3d578e5dc5908026ed780f9a240)
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>
(transplanted from 5526fb72a893f89286d6daa29da0161ca988a1d0)
On some Fedora boxen (at least FC13), it is also required
to link with libm when static ppl is used.
(transplanted from bcd33fce4db9c18223b59ecdc96f10bf6dd574de)
Replace the over-engineered and buggy test in CT_SanitizePath
with a straight forward string pattern match, and also
handle empty PATH elements which are qeuivalent to ".".
Thanks-To: Arnaud Lacombe <lacombar@gmail.com>
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Add CT_SanitizePath function which removes entries referring to ., /tmp
and non-existing directories from $PATH, and call it early in the
build script.
If . is in PATH, gcc-4.4.4 build breaks:
[ALL ] checking what assembler to use...
/tmp/build/targets/arm-unknown-linux-uclibcgnueabi/build/gcc-core-static/arm-unknown-linux-uclibcgnueabi/bin/as
...
[ALL ] config.status: creating as
i.e. "as" is supposed to be the arm-unknown-linux-uclibcgnueabi cross assembler,
but config.status creates a local "as" script which is calling the
host assembler.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
[Yann E. MORIN: style fixes + explanations]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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.
In C, the proper syntax for a bit-wise OR is a single '|', not two.
It worked so far because all was well:
- X_OK == 1
- R_OK||X_OK == 1
- the file we searched for had the x-bit set
-> access( file, R_OK||X_OK ) worked
- inicidentally, the file we searched for also had the r-bit set,
but we were not testing that in fact.
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'.
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/'.
