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>
Update the configuration and the comment.
Reported-by: Anthony Foiani <anthony.foiani@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Unconditionally create the lib32 -> lib/ and lib64 -> lib/ symlinks.
This is reportedly a fix to build a toolchain for a 32-bit target on
a 'pure' 64-bit host (eg. on Fedora FC12, host libs are in lib64/,
and there is no lib -> lib64 symlink, as we can see on other distors,
as Debian). As gcc only puts static host lib in lib64/ (along with
target files in subdirs), we can safely create the symlinks.
Also note that the symlinks are summarily removed at the end
of the build.
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
[Yann E. MORIN: fix a comment, rephrase the commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Do not fail in case either one or both of target/ and
.build/ directories are missing.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The toolchains are now built in .build/ rather than in targets/
so distclean has to get rid of that.
We also clean up the old dir, as users may have old samples that
still refer to the old location.
Do not hide messages during distclean, and do not ignore errors.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The place where toolchains were built has moved
from targets/ to .build/
We still ignore the old target/ dir, as users may have
samples that still use that location.
Also, reorder the ignore paterns.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
On a Fedora 12 x86_64 build/host box, this file was complaining about
PTRACE_PEEKTEXT being undefined. Adding in the "ptrace.h" include
fixed it.
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
Directly select-ing the required companion libraries means we can not
disable them. That's OK for now, as we systematically build them when
they are required.
But with distros coming up-to-speed, we will need to disable the build
later-on.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To decide whether we need to backup the companion libraries,
do not rely on the !shared case. In the future other cases
may require not to save the companion libraries (eg. if using
the ones provided by the host distro).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
check-lxdialog.sh breaks on 64-bit distributions which are lacking
the lib -> lib64 symlinks (eg. some Fedora).
The script from the 2.6.35 Linux kernel is reportedly functional
on the systems that were requiring the current hack. See:
http://sourceware.org/ml/crossgcc/2010-09/msg00113.html
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>
Both toolchains were tested to successfully:
- _build_ busybox, giving respectively an n32 and an n64 binary
although it has not been run-tested.
- build linux-2.6.36-rc3 for Loongson, giving an n64 vmlinux
(which is expected, due to the way the kernel is built),
and the kernel properly boots!
Credits are due to Julien MOUTHINO (julm on freenode#uClibc) for
testing that the kernel boots on his hardware! Cheers! ;-)
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>
Some archs (eg. ppc64 with n32 ABI) will install their
variants in lib32/ instead of lib/, so do for lib32 as
we do for lib64->lib symlinks.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Move the arch-specific options to the second-part of
the generated files, so they appear after the generic
options, but before the optimisations.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
'targets' is not really meaningfull.
'build' means what it means.
'.build' just hides it as well! :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The added code should be conditinal to the target system
being !MIPS, but is based on the host system being !MIPS.
This is plain wrong, and had not been noticed until now
as I never used those binutils versions on MIPS.
See:
http://sourceware.org/ml/crossgcc/2010-08/msg00192.html
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Remove those versions whose series does no longer appear on the
front page of kernel.org
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The help entries for each of the companion libraries are now
wrong, and anyway are not displayed. Nuke, nuke, nuke...
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>
Without this patch, crosstool-ng-built glibc-2.9 prevents
debugging any exeutable with gdb.
gdb says:
[Thread debugging using libthread_db enabled]
find_new_threads_callback: cannot get thread info: generic error
See also https://bugzilla.redhat.com/show_bug.cgi?id=487212
for a discussion of the bug and the solution.
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]
sstrip is causing more trouble and grief than tolerable.
It is broken at least on PPC. It does not build on non-ELF
systems (eg. mingw32, MacOS-X...). Plus, it is easy to
install.
Hide it behind OBSOLETE.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
