sstrip has been obsoleted for a while now, as it's still broken
for some archs, and there seems to be no incentive to fix it
upstream. Besides, the space gained with sstrip is marginal at
best.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <65c8bf534d0647ce52cd.1353320545@macbook-smorlat.local>
Patchwork-Id: 199970
Use the same method as companion tools for providing generic and
extendable companion libs.
Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <515c5c4635d99ebe4877.1353074410@macbook-smorlat.local>
Patchwork-Id: 199613
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
While eglibc-2.16 recommends to use TI-RPC instead of the old sunrpc, the
old one can be included using a configure option. Since the user can still
use TI-RPC to override the libc implementation, we enable rpc unconditionally.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Message-Id: <20121102140404.GA7707@sig21.net>
Patchwork-Id: 196564
We now have the ability to use a custom location, so supporting
snapshots or custom date is no longer needed. Let the user do the
required preparation in this case.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
We now have the ability to use a custom local directory/tarball, so
it no longer makes sense to have the ability to use the CVS repository.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since we now have the opportunity to use a custom local directory/tarball
as the source for gcc, it no longer makes sense to retrieve gcc ourselves
from its subversion repository.
Cc: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
That's legacy code that was usefull when ncurses was installed
in the sysroot. Still it's not longer the case (it's installed
in a special dedicated directory), we can remove that piece of
code.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
CUSTOM_LOCATION config options only presented in menuconfig if component
CUSTOM version selected.
Change elf2flt CT_ELF2FLT_VERSION from 'head' to 'cvs' if cvs selected in config
Also remove hardcoded 'cvs-' from elf2flt component name, used in CT_Extract,
CT_Patch and as the CT_SRC_DIR location for the configure stage.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
[yann.morin.1998@free.fr: fix indentation, don't patch custom dir location]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <288db3721a37844defa5.1349931196@localhost.localdomain>
PatchWork-Id: 190789
Currently, extract and patch are skipped as thus:
- using a custom directory of pre-installed headers
- a correctly named directory already exists
Otherwise, extract and patch are done.
The current second condition is wrong, because it allows the following
sequence to happen:
- a non-custom kernel is used
- a previous build only partially extracted the non-custom sources
- that p[revious build broke during extraction (eg. incomplete tarball...)
- a subsequent build will find a properly named directory, and will
thus skip extract and patch, which is wrong
Fix that by following the conditions in this table:
Type | Extract | Patch
----------------------+---------+-------
Pre-installed headers | N | N
custom directory | N | N
custom tarball | Y | N
mainstream tarball | Y | Y
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: David Holsgrove <david.holsgrove@xilinx.com>
Config options remain the same as before, just generalised to be used by other
components also.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
[yann.morin.1998@free.fr: fix indentation, fix comment]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <50674fe47431174aab80.1349931193@localhost.localdomain>
PatchWork-Id: 190786
Previous import from patchwork missed one hunk (in cset #d8feb93b3e49)
Apply it now.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Patchwork-Id: 189053
Attempting to ${CT_TARGET}-gcc -print-multi-lib will fail
In do_cc_core_backend, for the final compiler in a canadian cross
baremetal, warn that multi-libs cannot be determined
In do_cc_backend, for either final compiler for a canadian cross,
warn that multi-libs cannot be determined
(Plus fixed CT_PREFIX_DIR in do_cc_backend to be ${prefix})
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Message-Id: <CAM=EW8aQDoNx-CkJHjXBoDP4iTDJ8z5hh3=KhO5UTU6rp3Pj=w@mail.gmail.com>
Patchwork-Id: 189053
--with-expat=yes is unconditionally passed to the gdb configure
stage, instead of respecting the ${do_expat} decision.
Disable if not needed. Prevents error building canadian cross;
configure: error: expat is missing or unusable
Where configure stage fails to find expat on the host compiler.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Message-Id: <4c4410a2a8aab24a29c5.1349244128@localhost.localdomain>
PatchWork-Id: 188711
GCC requires m68k arch tuples to be *-*-uclinux-* to support Linux on
no-mmu m68k (ColdFire) cpus.
Blackfin arch tuple must be *-*-linux-uclibc for FD_PIC_ELF toolchains,
so we cannot just switch to uclinux for no-mmu Linux toolchains.
Signed-off-by: "Esben Haabendal" <esben@haabendal.dk>
Message-Id: <876271s1ee.fsf@arh128.prevas.dk>
PatchWork-Id: 186976
build fails to symlink to custom kernel dir when the build is not the first time
because of 'ln -s' without '-f' option.
Signed-off-by: "Jang, Bongseo" <graycells@gmail.com>
Message-ID: <543e2981f2b723ecd850.1348370892@localhost.localdomain>
PatchWork-ID: 186178
Add Microblaze architecture support.
This depends on EXPERIMENTAL, as upstream projects do not yet
include full support to build a modern microblaze compiler.
This is in the process of being updated, but is not currently
publicly accessible.
Signed-off-by: "David Holsgrove" <david.holsgrove@xilinx.com>
Message-Id: <9c93e18b3d68b19303f3.1348113870@localhost.localdomain>
PatchWork-ID: 185305
I took some of the svn functionality from eglibc.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@free.fr: fix the conditional test in build script]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
That comes from way back when nothing would work as expected, and I would
easily get heated as soon as anything would break. Sigh, those were the
old days.
Apologies.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
For expat, duma, and strace, use the generic url and 302 to the mirror
instead of trying to download a file from a downed mirror and
failing.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Message-Id: <b69ebeb72fef93c04c84.1345364051@flambe.is-a-geek.org>
Whatever the threading model (NPTL, LT...), we build the same
core pass-1 compiler, so there is no need to have a case-esac
construct.
Remove now mis-leading and incorect comment.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Both core pass-1 and -2 compilers are unconditionally built,
so we no longer require a condition variable.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Up until now, all conditions requiring a core pass-1 was when the
threading implementation used was NPTL. So we only built the core
pass-1 when NPTL was used.
Now, things have changed (what? when? Dunno...), and some bare-metal
canadian toolchains fail to build if a core pass-1 is not present.
OTOH, a core pass-1, although not needed for non-NPTL builds, does
no harm at all if it is present.
So, unconditionally build a core pass-1 (but still pass conditional
options to the core backend).
Reported-by: Per Arnold Blaasmo <Per-Arnold.Blaasmo@atmel.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Because we now patch configure.in and configure, the Makefile quicks
in a re-build rule as the source files are now more recent than the
bundled generated files, and that fails because the m4 directory
is missing, although on some systems where aclocal is not installed,
the re-build rule does nothing (except a warning).
Always create tht directory.
Reported-by: Per Arnold Blaasmo <per-arnold.blaasmo@atmel.com>
[Also thanks to Thomas De Schampheleire <patrickdepinguin@gmail.com>
for some digging works on this issue]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
gdbserver >= 7.2 comes with an optional library to use tracepoints, the
In Process Agent (IPA) library, libinproctrace.so.
Currently, we build gdbserver staticaly, but that breaks the build of
the IPA lib.
Add an option to biuld the IPA lib, but not if statically linking.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
During application development it is desirable to enable malloc
debugging and LD_DEBUG support, but the extensive debug spew from
SUPPORT_LD_DEBUG_EARLY is only useful when working on
uClibc's ld.so.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Currently, we rely on an existing external cross-compiler targetting
the target, to build the C library.
This can pause quite a few problems if that compiler is different from
the one we are building, because it could introduce some ABI issues.
This patch removes this dependency, by building the core compilers
as we do for standard cross, and also by building the binutils and
gcc, for running on the build machine.
This means we no longer need to offer the cross-sompiler selection in
the menuconfig.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Bizarrely enough, the core gcc are not enough to be able to build a
canadian cross, and a real, full cross compiler is required so that
the canadian cross can be properly built... WTF?!? Sigh...
Add a build-frontend, as was done for the binutils and the complibs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Do for the final step the same as for the core step: compute the list
of selected langauages from the frontend, not in the backend.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
As the core backend can be used to also build the bare-metal compiler,
we have to tel it what languages to build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add a function that prepares the language configure option.
It is needed in at least two places, some commonalisation is needed. ;-)
Unfortunately, it is no longer possible to print warnings about experimental
languages any more. Anyway, the experimental status is clearly indicated
in the menuconfig. so it should not be a surprise if the build breaks. :-/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It's easier to have as much as possible stuff in the same place to
ease backup/restore, and make things easier to follow.
Move the host companion libraries install dir as a sub-dir of the
build-tools install dir (but not directly in it, it would break
for canadian or cross-native).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
A few noop fix-ups:
- fix the comments in core pass-1
- commonalise settings that can be
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In canadian-cross, we need the companion libraries running on the
build machine, to be able to build the two core gcc.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In canadian-cross, we need binutils running on the build machine to be
able to build the target C library.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Move the actual complibs codes to backend functions that builds the
required combo of build/host/target as requested by a frontend.
This split is currently a no-op, but is required for the upcoming
canadian-cross rework, where we'll be needing to build the complibs
twice, one for build/build, and one for build/host.
This applies to the six companion libraries:
- GMP
- MPFR
- PPL
- Cloog/PPL
- MPC
- libelf
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Move the actual binutils code to a backend function that builds the
required combo of build/host/target as requested by a frontend.
This split is currently a no-op, but is required for the upcoming
canadian-cross rework, where we'll be needing to build two binutils,
one for build/build/target, and one for build/host/target.
This applies to the three binutils:
- GNU binutils
- elf2flt
- sstrip
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The core compilers are used to build the C library, so they
should always run on the build machine, not on the host.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
There really is no good reason to install the core compilers in their
own places, one for each pass. We can install them with the other
build tools.
Also, this implies that:
- there are fewer directories to save/restore
- there are fewer symlinks to create for binutils
- the PATH is shorter
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building a canadian-cross, the binutils are not executable on
the build machine, so there is no point in installing the symlinks
in the gcc static/shared install dirs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
strace upstream location has slightly changed.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since anciens.enib.fr has been dead for two months now, without any
hope of recovery, update my e-mail to point to @free.fr instead.
Reported-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
The build dir are created depending on the host (host for that specific
backend, not host for the toolchain). Only the frontends know what host
this is, so only the frontends can create non-ambiguous dirs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The only user of the static core compiler in pass-1 was the newlib
C library. Now that it is build in a later step, we do no longer
need to build a static core compiler in pass-1.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, newlib is built in the start_file step, which is wrong, but was
needed when the baremetal integration was... well, 'unfinished'.
Now that we build the baremetal compiler from the final cc step, and a
proper core gcc in pass-1 and pass-2, we can move the newlib build to the
step do_libc, where it belongs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In case we build a baremetal compiler, use the standard passes:
- core_cc is used to build the C library;
- as such, it is meant to run on build, not host;
- the final compiler is meant to run on host;
As the current final compiler step can not build a baremetal compiler,
call the core backend from the final step.
NB: Currently, newlib is built during the start_files pass, so we have
to have a core compiler by then... Once we can build the baremetal
compiler from the final cc step, then we can move the newlib build to
the proper step, and then get rid of the core pass-1 static compiler...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, we issue the bare-metal compiler from the pass_1 & pass_2
core compilers, because the final gcc breaks while doing so.
This implies we have to build some libces during the start_files step,
instead of the standard libc step. This is the case for newlib.
By adding a backend/frontend infra to the final gcc, we can abstract
what backend to call: the standard backend for non-bare-metal gcc,
and the core backend for bare-metal.
This patch is just an no-op, it just adds the final backend and
frontend without changing the way bare-metal is built, to come in a
subsequent patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
As the core backend is used to generate the bare-metal compiler,
we need to pass it the host CFLAGS.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Tell the core compiler what host it should run on (instead of
hard-coding runing on CT_HOST).
No functional change so far, switching between CT_HOST and CT_BUILD
will come in a following patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, the discrimination on the core compilers prefixes depends on
the type of core compiler to build.
This is not correct, and the caller of the core backend should specify
the prefix.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In case of canadian-cross, the companion libraries are not the same for
the core cc (they run on 'build') as they are for the final cc (they run
on 'host').
Prepare for this differentiation (coming later), while retaining the
current behavior (to use the same compblibs).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Rename the core backend function to do_cc_core_backend, to
make it explicit it is a backend.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The core backend is going to have more parameters in the upcoming
patches, so it will be a bit complex to handle.
Introduce an array-variable that is filled by the different code-paths
with the required values.
This makes the code easier to read and maintain.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The current construct consumes the parameters while we parse them.
Change this to a construct that does not consume the parameters.
This has no impact on gcc, but is done for homogeneity with other
components (eg. glibc).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, there are two constructs used to parse arguments in
glibc backends, one that consumes args as they are parsed, and
one that does not.
Always use the construct that does not eat args as they are parsed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It seems sourceforge changed yet again the way to download files.
This time, no longer use their 'mesh' thingy, and hard-code the
server to use in the URL... Sigh... :-(
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
sim was already disabled for CT_GDB_NATIVE.
Reviewed-by: Michael Hope
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@anciens.enib.fr: make it a config option]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In Ubuntu 11.04 and 11.10, the default options for ld have changed.
--no-copy-dt-needed-entries and --as-needed are now enabled by default, which
causes errors like:
[EXTRA] Checking CLooG/ppl
[DEBUG] ==> Executing: 'make' '-j3' '-s' 'check'
[ALL ] Making check in .
[ALL ] config.status: creating include/cloog/cloog-config.h
[ALL ] config.status: include/cloog/cloog-config.h is unchanged
[ALL ] libtool: link: i686-build_pc-linux-gnu-gcc -Wall -fomit-frame-pointer
-pipe -o cloog cloog.o -L/<snip>/build/static/lib ./.libs/libcloog.a -lm
/<snip>/build/static/lib/libppl_c.a /<snip>/build/static/lib/libpwl.a
/<snip>/build/static/lib/libppl.a /<snip>/build/static/lib/libgmpxx.a
/<snip>/build/static/lib/libgmp.a -lstdc++
[ALL ] /usr/bin/ld: /<snip>/build/static/lib/libppl.a(MIP_Problem.o):
undefined reference to symbol 'sqrt@@GLIBC_2.0'
[ALL ] /usr/bin/ld: note: 'sqrt@@GLIBC_2.0' is defined in DSO
/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/libm.so so try adding
it to the linker command line
[ALL ] /usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/libm.so:
could not read symbols: Invalid operation
[ALL ] collect2: ld returned 1 exit status
[ERROR] make[2]: *** [cloog] Error 1
[ERROR] make[1]: *** [check-recursive] Error 1
See:
https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
This patch fixes these errors by placing '-lm' at the right place on the command
line as libppl requires libm when linking cloog.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Installing the gcc test-suite can take a bit of time, so the
progress bar is currently not rotating because there is no
output during the copy. For an unsuspecting user, it could
mean the process hung.
With 'cp -v', the progress bar now rotates.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When doing multilib, we only need the headers from the default variant,
but we need the startfiles for each variants.
Allow the frontend to specify either one, or both.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
For mutlilib, the C library must be built once for each variants.
Special care must be taken to put the resulting libraries in
the proper places.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building a multilib variant, install in a separate directory, to
avoid clutering the default or any other variant.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building a multilib, some extra CFLAGS can override the
default config option. This is the case for the endianness
selection.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building a multilib, some extra CFLAGS can override the
default config option. This is the case for the floating point
selection.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When building multilib, we need extra CFLAGS that tell the compiler
to use non-default settings (eg. big/little endian, hard/soft float,
-march/cpu/tune flags, and so on...).
We have to pass these flags to the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The caller SHALL explicitly ask for a nmode, and not rely on a default mode.
That's what actually happens, so we can get rid of the default.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In some cases, it might be desirable to use the system zlib
Eg. because latest gcc seem to be totally borked when it comes
to multilib, and tries to build a multilib host zlib, when it
is *absolutely* *not* needed: we want mulitlib on the target,
not on the host! Sigh... :-(
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The localedef of eglibc 2.14 requires NOT_IN_libc to be defined in order to
compile intl/l10nflist.c.
This is because localedef is built separately from eglibc and uses some parts of
eglibc that don't compile in standalone without this preprocessor definition.
This fixes the following error:
[ALL ] gcc -g -O2 -DNO_SYSCONF -DNO_UNCOMPRESS
-DLOCALE_PATH='"/usr/lib/locale:/usr/share/i18n"'
-DLOCALEDIR='"/usr/lib/locale"' -DLOCALE_ALIAS_PATH='"/usr/share/locale"'
-DCHARMAP_PATH='"/usr/share/i18n/charmaps"'
-DREPERTOIREMAP_PATH='"/usr/share/i18n/repertoiremaps"'
-DLOCSRCDIR='"/usr/share/i18n/locales"' -Iglibc/locale/programs -Iglibc/locale
-I/<snip>/.build/src/eglibc-localedef-2_14/include
-I/<snip>/.build/src/eglibc-localedef-2_14 -I.
-include /<snip>/.build/src/eglibc-localedef-2_14/include/always.h -Wall
-Wno-format -c -o locarchive.o glibc/locale/programs/locarchive.c
[ALL ] glibc/locale/programs/locarchive.c: In function 'enlarge_archive':
[ALL ] glibc/locale/programs/locarchive.c:303:21: warning: variable
'oldlocrectab' set but not used [-Wunused-but-set-variable]
[ALL ] In file included from glibc/locale/programs/locarchive.c:651:0:
[ALL ] glibc/locale/programs/../../intl/l10nflist.c: In function
'_nl_normalize_codeset':
[ERROR] glibc/locale/programs/../../intl/l10nflist.c:342:9: error:
'_nl_C_locobj_ptr' undeclared (first use in this function)
[ALL ] glibc/locale/programs/../../intl/l10nflist.c:342:9: note: each
undeclared identifier is reported only once for each function it appears in
[ALL ] glibc/locale/programs/locarchive.c: In function
'add_locales_to_archive':
[ALL ] glibc/locale/programs/locarchive.c:1450:7: warning: passing argument
1 of '__xpg_basename' discards 'const' qualifier from pointer target type
[enabled by default]
[ALL ] /usr/include/libgen.h:35:14: note: expected 'char *' but argument is
of type 'const char *'
[ERROR] make[1]: *** [locarchive.o] Error 1
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@anciens.enib.fr: copy with a single call to 'cp']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The changeset 2467 #200836977ce6 missed renaming one occurrence of
CT_BINUTILS_EXTRA_CONFIG to CT_BINUTILS_EXTRA_CONFIG_ARRAY, which is fixed by
this patch.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Some longterm versions are not in the usual directory.
Account for these new locations.
Get rid of the mirror location, now that the main kernel site is
(almost) back to normal operations.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
With hard-coded "-O", users can not customize CFLAGS_FOR_TARGET
by CT_TARGET_CFLAGS. If "-O" is needed, users can input it in
CT_TARGET_CFLAGS. By default, "-Os" is enabled.
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@anciens.enib.fr: prompt rewording, as suggested by M. Hope]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Otherwise, users have to input --disable-libstdcxx-pch option
when building bare-metal CANADIAN C++ compiler.
Reviewed-by: Michael Hope
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
Add support for building the HTML and PDF manuals for the major
components. Implement for binutils, GCC, GDB, and GLIBC.
Always build all manuals and install a subset. Be explicit about the
subset to reduce the clutter and to avoid getting copies of common
manuals like bfd from all of the sourceware based components. Downside of
being explicit is that you need to update it when a new component
comes along.
Build the manuals as part of the last GCC build, namely 'cc' for glibc
based ones and cc_core_pass_2 for baremetal.
An example of the output is at:
http://people.linaro.org/~michaelh/incoming/crosstool-NG/
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: depends on ! remove docs; gold manual install]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In the early days, cloog-ppl was bizarrely packaged: the first tarball
did not contain the version in the name of the extracted directory, so
we had to play tricks.
Nowadays, however, the first component of the path are stripped when
extracting a tarball, which means that the created directory will
always be properly named. So, our old tricks do no longer work, and
worse, they break the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
ncurses 5.9 wants tic to be either one of:
- $TIC_PATH
- /usr/bin/tic
Of course, se do not want the latter, for it can be incompatible if the
ncurses in the build system is too old (eg. RHEL 5.6, Debian Lenny...).
So, force TIC_PATH to the location of our own tic.
Also, install tic alongside the other build tools, not in a sub-dir
of the toolchain installation dir.
Signed-off-by: Willy Tarreau <w@1wt.eu>
[yann.morin.1998@anciens.enib.fr: install in builtools/bin, move TIC_PATH]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some architectures support a mixed hard/soft floating point, where
the compiler emits hardware floating point instructions, but passes
the operands in core (aka integer) registers.
For example, ARM supports this mode (to come in the next changeset).
Add support for softfp cross compilers to the GCC and GLIBC
configuration. Needed for Ubuntu and other distros that are softfp.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split the original patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
With the upcoming softfp support, the case..esac test would become
a bit convoluted if it were to test three different booleans.
Introduce a new blind string config option that defaults to the
selected floating point type used.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
[yann.morin.1998@anciens.enib.fr: split the original patch]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Changeset #7c288c777455 broke the tuple for uClibc-based
powerpc toolchains, by unconditionally forcing CT_TARGET_SYS
to "gnu".
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Tremendously helps when running on at least Ubuntu, with dash as
the system shell (ie. /bin/sh points to dash).
Reported by a few people, of which:
leming, ccct and ccole on IRC
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add a new option to enable/disable the Python scripting in gdb.
Hide the option (ie. disable it) when statically linking the cross-gdb.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The GOLD linker is written in C++. Pass CT_CFLAGS_FOR_HOST as
CXXFLAGS to configure so that any host specific flags are passed
through.
It feels a bit funny passing CFLAGS as CXXFLAGS, but the PPL and GCC
target rules already do the same.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
Allows using either a tarball or a directory as the custom kernel
source location.
Signed-off-by: Vincent BENOIT <sinseman44@gmail.com>
[yann.morin.1998@anciens.enib.fr: fix space damage, detailed commit message]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Since kernel.org is dead, and there is no announced or known estimated
time or return to normality, it is impossible to download any kernel at
this time.
Add a known-working mirror.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Even if the current process is highly parallel, crosstool-NG spends most
of its time in single-job steps on fast machines (with a 12-CPU system,
I approximate the parallel vs. non-parallel time to be in the order os
1 to 3; that is crostool-NG spends two-thirds of its time running
non-parallel jobs).
Some steps to build gcc can be paralleled, gaining a litle bit of time
on the whole compilation.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Allows to choose if one wants to keep or not the syscalls that are provided with
newlib. It passes the --disable-newlib-supplied-syscalls or
--enable-newlib-supplied-syscalls to the configure script. If one chooses to
disable the builtin syscalls, he/she will have to write his/her own. This can
be usefull to port newlib to a new platform/board.
Signed-off-by: Kévin PETIT <kpet@free.fr>
HOST_OS really is the target OS. Allow setting it for configure
via an environment variable.
libltrace.a should have an index:
Allow ar to be set as an environment variable, and generate
an index in this lib.
Reported-by: "Guylhem Aznar" <crossgcc@guylhem.net>
Signed-off-by: "Titus von Boxberg" <titus@v9g.de>
Because we need our own host tic, we have to build it; and we do build
it statically for now.
But as MacOS/Darwin/Whatever-you-call-it does not support static linking
(what a shame!), it fails.
Anyway, we don't really care it being shared, in the end.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The custom-tarball symlink was created in CT_SRC_DIR, when it
should be created in CT_TARBALLS_DIR.
Reported-by: Guylhem Aznar <crossgcc@guylhem.net>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Simplify the way the custom tarball is handled:
- fake version="custom"
- at download, simply link the custom tarball to:
"linux-custom.${custom_extension}"
- at extract, the above allows to simply extract "linux-${LINUX_VERSION}"
where LINUX_VERISON is set to the fake version="custom"
Not that much convoluted, in fact... :-/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Although ctor/dtor do not seem strictly required, missing them proves
rather inconvenient, as ld can't link binaries.
Reported-by: John Spencer <maillist-uclibc@barfooze.de> (sh4rm4 on IRC)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
do_libc_locales_extract() and do_libc_locales() in glibc-eglibc.sh-common have
been overridden for both glibc and eglibc, so they can now be removed, which
this patch does.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch adds partial support for glibc locales.
For now, it only generates the appropriate locales when the host and the target
have the same endianness and uint32_t alignment.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch adds a common glibc/eglibc infrastructure to build and install the
libc locales.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Someof the mingw32 source tarballs have an appended '-src' after the
version.
Since changeset #6e1412ba8da9 (scripts/functions: force extract folder
to archive basename), it means mingw tarballs get extracted in a directory
ending with '-src'.
Fix that.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Now that we akways extract the tarballs in a sane location (see changeset
#6e1412ba8da9: scripts/functions: force extract folder to archive basename),
the uClibc snapshot dir now has the date (as version) in it, eg.:
uClibc-20100710
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, no --enable-add-ons option is passed to libc configure when
"$(do_libc_add_ons_list ,)" is empty, which makes configure automatically search
for present add-ons. In that case, all present add-ons are built, although
no add-on was selected by the user in the config. Moreover, this can make the
configure fail if some non-standard add-ons like eglibc-localedef are present.
This behavior also leads to an inconsistency from a user point of view between
the following cases:
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS="none" in the config,
which makes "$(do_libc_add_ons_list ,)" return "", so all present add-ons
are built.
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS!="none" in the
config, which makes "$(do_libc_add_ons_list ,)" return the add-on supporting
the chosen threading implementation, e.g. "nptl", so only this add-on is
built.
This patch disables the building of all add-ons in that case.
It is still possible to build all present add-ons by adding --enable-add-ons to
LIBC_GLIBC_EXTRA_CONFIG_ARRAY.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
gdb needs to know where to find the libstdc++ helper python script
to do, well, whatever it has to do with it...
We can't install that in the user's ~/.gdbinit, it's too complex to
handle all the cases. Moreover, if the user is using more than one
toolchain, we can't put all that stuff in there...
Just provide a sample config file the user can adapt to his/her
own needs.
Thanks go to Khem RAJ for providing such a hint:
http://sourceware.org/ml/crossgcc/2011-07/msg00026.html
Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
CC: Khem Raj <raj.khem@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The place to get 3.x has changed; the version scheme has changed.
No need to be overkill, just support 3.x; 4.x is not even dreamt of.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the user builds a toolchain over an existing one, so, without removing
CT_PREFIX_DIR, the build fails as the symlinks already exist, as does the
build.log.
This can also happen (for build.log) if the user first ran in download-
or extract-only.
Patch (with no SoB) originally from:
Phil Wilshire <phil.wilshire@overturenetworks.com>
Modified by me as it did not apply cleanly.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
During the build, we create lib{32,64}/ symlinks out of the sysroot.
In some cases (eg. mingw32 target), these symlinks are still required
when running the toolchain. For other combinations, the symlinks are
without incidence, so they can be safely kept after the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The new MIPS-specific options are not valid for other targets.
Also, move the arch-specific setting lower in the extra_config setting.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add the following MIPS specific options when configuring gcc:
--with(out)-llsc
--with(out)-synci
--with(out)-mips-plt
--with-divide=type
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add an option to specify the hash type that gcc will ask the linker to use.
It is a provision for the upcoming 4.7, as no version currently supports it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add an option to configure gcc with --enable-linker-build-id.
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Instead of getting eglibc over standard svn://svn.eglibc.org
Add an option that allows the user to get source from
http://www.eglibc.org/svn
This is useful if you are behind a firewall or proxy.
If you are behind a proxy, don't forget to configure
${HOME}/.subversion/servers
In the [global] section setup your proxy configuration.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@anciens.enib.fr: removed useless 'default n']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
That option is coming from the original crosstool, and is not entirely
understand here.
Moreover, it breaks with newer gcc-s: 4.6.1 now breaks while configuring
libjava (and probably some other libs as well, untested).
There is an related bug report to the gcc BZ:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49555
If need be, the old behavior can be restored with:
CC_CORE_EXTRA_CONFIG_ARRAY="--enable-symver=gnu"
CC_EXTRA_CONFIG_ARRAY="--enable-symver=gnu"
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Refactor the contents of 'do_libc_start_files()' and 'do_libc()' into a
parameterized 'do_libc_backend()'. 'do_libc_start_files()' and 'do_libc()'
call 'do_libc_backend()' with either 'libc_mode=startfiles' or
'libc_mode=final' (respectively) so that the startfiles/headers and
the final libc builds are configured and built with the same options.
One example of where this is needed is when building a mips toolchain.
Previously, if you were building an n32 toolchain, you wouldn't have
noticed an issue, because if '-mabi' is not in CFLAGS, n32 is the
default:
http://sourceware.org/git/?p=glibc-ports.git;a=blob;f=sysdeps/mips/preconfigure;hb=HEAD
But when trying to build an o32 or n64 toolchain the build would
have failed. This is because (e)glibc expects "-mabi={o32,n32,n64}" to be
in CFLAGS, but was not previously provided in 'do_libc_start_files()'.
The build failure would happen in the shared-core gcc when it tries to
configure an n64 or o32 gcc with an n32 libc.
A simpler solution would have been to just add TARGET_CFLAGS to configure
in 'do_libc_start_files()', but this way makes configure and make
consistent for both steps.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Cross-gdb depends on expat and python. If either is missing, cross-gdb will
build successfully, but lacking some features.
Especially, if expat is missing, cross-gdb will be unable to parse the target
description, which may lead to runtime malfunctions and the following GDB
warning:
"Can not parse XML target description; XML support was disabled at compile time"
Hence, expat should be considered mandatory.
On the other hand, the features missing without python are not critical, so
python should not be considered mandatory.
This patch does the following:
- At configure time, warn the user if either expat or python is missing.
- In menuconfig, disable the static build options regarding cross-gdb if no
static version of expat is available, and disable cross-gdb if expat is
missing.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
[yann.morin.1998@anciens.enib.fr: add comment for impossible static cross-gdb]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The NPTL add-on has always been internal, so there is no
reason to try downloading it, it will never succeed.
Add provision to skip other add-ons as well.
For consistency, do the same test in both glibc and eglibc.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
"crosstool-NG-${CT_VERSION}" is currently the default for TOOLCHAIN_PKGVERSION,
and this options is passed as is to --with-pkgversion.
This patch prepends "crosstool-NG ${CT_VERSION}" to TOOLCHAIN_PKGVERSION before
passing it to --with-pkgversion.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Some addons are bundled with glibc/eglibc, so we should not try to
download and extract them.
This is done as thus:
- at download time:
- if the add-on download fails, keep going;
- at extract time:
- if the addon is present in the source tree, ignore it;
- if the addon is missing in the source tree:
- if the archive is present, extract it;
- if the archive is missing, bail out.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
eglibc is only available from SVN. The script currently calls svn
in its own tortuous and convoluted way.
Use the egeneric SVN extract functions, and sinplify the eglibc
download function.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This patch makes gdb benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch makes eglibc benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch makes binutils benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch promotes the PKGVERSION and BUGURL options to toolchain level so that
all toolchain components supporting them can benefit from them.
These options are passed to configure through --with-pkgversion and
--with-bugurl.
They are supported by binutils 2.18+, gcc 4.3+, eglibc 2.9+ and gdb 7.0+.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
glibc and eglibc have a very similar extraction process, so it
makes sense to commonalise it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Fixes the issue with {e,}glibc addons having short and long names (such as
eglibc-ports-2_13 and ports), which caused configure scripts to run
through them twice and thus configuring incorrectly.
For instance, the mips64el-n32-linux-gnu toolchain would be recognized
correctly first, but then the second pass would change it to mips32,
building a mixed MIPS-III N32 and MIPS-I libc.
Signed-off-by: Nicolás Reynolds <fauno@kiwwwi.com.ar>
[yann.morin.1992@anciens.enib.fr: remove spurious trailing spaces]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This patch sets the runtime sysroot to fix the following GDB warning:
"Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code."
The sysroot can later be changed within gdb with the `set sysroot`
command if necessary.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Make it explicit that a variable is an array bu the name of the variable.
It will be used later when .config gets munged to allow both multiple
arguments and arguments with spaces at the same time to be passed from the
configuration down to the build scripts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
By default, PPL wants to build interfaces for any of a variety of
langauges it finds on the local host (python, java, possibly perl, also
more esoteric languages such as ocaml and prolog).
These extra interfaces can double the compile time for the library. For
single-process builds, I found a savings of more than 40%:
default / j1: 716s total, 143.2s avg, 0.52s stdev
just_c / j1: 406s total, 81.2s avg, 0.33s stdev
just_c_cpp / j1: 413s total, 82.6s avg, 0.22s stdev
And for multi-process builds, it approached 50%:
default / j4: 625s total, 125.0s avg, 0.57s stdev
just_c / j4: 338s total, 67.6s avg, 1.25s stdev
just_c_cpp / j4: 327s total, 65.4s avg, 0.36s stdev
Since the PPL we build within ct-ng is only used by GCC, we only need to
build the C and C++ interfaces.
Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
PPL does not use the "--enable-cxx" configure switch at all; it's
possibly a cut-and-paste leftover from 'gmp.sh'. (PPL is written in C++
natively, so it doesn't make much sense to have to enable C++; GMP, on
the other hand, is written in C with an optional C++ wrapper.)
Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
'configure' for PPL 0.11 (and later) needs "--with-gmp-prefix" to
provide the location of the GMP toolkit; the previous switches were
"--with-libgmp-prefix" and "--with-libgmpxx-prefix".
The upstream log message is:
commit 08dfb6fea094f8c5a533575a3ea2095edce99a6d
Author: Roberto Bagnara <bagnara@cs.unipr.it>
Date: Sun Jul 12 21:39:46 2009 +0200
New configure option --with-gmp-prefix supersedes the (now removed)
options --with-libgmp-prefix and --with-libgmpxx-prefix.
Link: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=08dfb6fea094f8c5a533575a3ea2095edce99a6d
Since PPL's 'configure' ignores unknown switches, we use all three so we
don't have to conditionalize the ppl.sh build script itself.
Signed-Off-By: Anthony Foiani <anthony.foiani@gmail.com>
Fix typo introduced by changeset #055e505f28be.
Also, handle older versions of gcc (typically, all versions
prior to 4.0.0).
Maxime provided a similar patch, missing the case for the
legacy versions of gcc.
Reported-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
We can't run the newly built gcc when it is a canadian cross.
Thus, we can't get the version number, and thus we can't get
the directory libexec subdirectory to strip.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gcc installs the C++ headers in ${PREFIX}/include/ but we trash
that directory at the end of the build.
We previously removed that directory as it contained the companion
libraries header files. But it's been some time now that we isntall
the companion libraries in their own dedicated place, so we do not
need to remove that directory.
Until we have a better fix, just keep that directory for now.
Reported-by: Bob Rossi <bob@brasko.net>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Managing the shared version of the companion libraries
has become cumbersome.
Also, it will one day be possible to use the companion
libraries from the host distribution, and then we will
be able to easily use either shared or static libs.
As a side note, while working on the canadian-rework
series, it has become quite more complex to properly
handle shared companion libraries, as they need to be
built both for the build and gost systems. That's not
easy to handle. At all.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is not capable of building glibc/eglibc, so we have to
force using the BFD linker, ld.bfd.
Offer a blind option that affected components can select to
force use of the BFD linker during the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add support for building SPARC targeted toolchain.
With this patch I have built a working sparc V8 (32 toolchain).
Testing shows that not all gcc versions works well:
4.4.1 OK (kernel builds and the final kernel can boot)
4.4.2 Not tested
4.4.3 Not tested
4.4.4 BAD (Kernel can build but fails during boot)
4.4.5 BAD (Kernel can build but fails during boot)
4.5.1 BAD (Build fails with a spill related ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664)
4.5.2 OK (kernel builds and boots)
I have successfully been using the 4.5.2 version for a few months.
This patch does not add support for the LEON variant.
That may come later.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[yann.morin.1998@anciens.enib.fr: for 32-bit, default CT_TARGET_ARCH is OK]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
PPL 0.11+ installs three libs: lippl, libppl_c and libpwl.
libppl_c has a dependency on libpwl (at least for watchdog stuff).
While gcc correctly links with libppl and libppl_c, it does not
pull libpwl in. In case of shared libs, this is not a problem, as
libppl_c has a NEEDED dependency on libpwl. But for static libs,
that does not work. Although libppl_c.la exists and has a correct
dependency on lipwl, somehow gcc misses it. So we have to force
pulling libpwl when needed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
There was a mishap when cut-n-pasting code from the final
step into the core step: a variable was not renamed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some scripts have 'very long lines', so the output of 'file'
will have that mentioned, such as:
POSIX shell script, ASCII text executable, with very long lines
Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The heuristic to find shell script is deficient. Fix it.
Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Building the start files requires a shared-capable compiler, which we do
not have when the threading implementation is LinuxThreads.
So, only build the start files when the threading implementations is NPTL.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
By default, recent versions of glibc and eglibc will build some
functions that take format strings (eg. printf, syslog...) with
run-time checks against some format string attacks. This is
called a fortified build.
Unfortunately, this fails somehow while building the instrumented
version of syslog, with some kind of circular dependency...
Disable fortified builds by default, and hide the enabling option
behind EXPERIMENTAL for daring users...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
As companion tools might or might not be used to build each
toolchain, they do belong to that toolchain's build tools,
not to the generic override tools.
Fix a typo in the autoconf URL.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The gcc used by linaro has a version number specific to Linaro, but
identifies itself with its upstream version numbering scheme.
This breaks the strip in the finish step, because the actual gcc version
is not the same as the configured one (eg. 4.5.2 vs. linaro-4.5-2011.02-0).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
We make it an option, as not all combinations of architectures
vs. compiler vs. glibc/eglibc exhibit the issue. Mostly visible
on old glibc versions, it seems...
This is a missing part from the glibc/eglibc merger... :-/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Enabling plugins in binutils is not enough, and gcc also
needs to be ./configured with --enable-plugins, although
this is not documented anywhere... :-/
Reported-by: karthik duraisami <kdconstant@hotmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Since the advent of make-3.82, some packages now break due to changes
in make-3.82, being stricter than 3.81 when interpreting the Makefiles.
This has bugged us a bit too much so far, and I believe fixing all
of them is a long road, while simply building make-3.81 is the easiest
route for now.
Of course, in the long term, packages will get fixed upstream, and we
should back-port the fixes to old versions, and get rid of building
make-3.81. In the meantime...
Reported several times on the mailing list.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Under mingw, it seems that there is a mix between the traditional /usr
directory, and a similar-purposed /mingw directory (both in the sysroot).
Currently, we create /mingw as a symlink to /usr, and we removed it in
the libc-finish step.
Unfortunately, this prevents the pre-processor to find the headers.
Keeping the symlink makes it magically work...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Depending on local policies, some users have expressed a need to
have the sysroot be named differently than the hard-coded name.
Add an option for that.
Default to 'sysroot' to match the existing literature.
While at it, replace 'sys-root' with 'sysroot' everywhere we
reference the sysroot.
Reported-by: Alexey Kuznetsov <Alexey.KUZNETSOV@youtransactor.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Final step at sharing code between glibc and eglibc.
Fall, wall of shame, fall!... :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The reunification of the glibc/eglibc code paths exposed a nasty
bug in the glibc build: use of PARALLELMFLAGS breaks the build.
See the explanations in that bug report against FC6:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=212111
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
glibc and eglibc each have two very similar ways of building this list.
This can, and should definitetly, be shared.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It will be possible to use that also with eglibc, so this hunk belongs to
the common code.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Use the common procedure, shared between glibc and eglibc. This requires
that glibc-specific bits be included in the shared procedure.
But still build the full libc with the glibc-specific procedure. This will
be commonalised in a future commit.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The build procedure for eglibc is generic enough to
be shared between glibc and eglibc. This includes:
- headers install (empty!)
- start files build
- complete libc build
- libc finish (empty!)
- add-ons list
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It is unnecessary to split C library preparation into two steps, as only
one really makes sense. So, do_libc_headers is bound to be withdrawn
short-term, in favor of do_libc_start_files.
mingw already had all its start files installation in do_libc_headers, and
do_libc_start_files was empty, just migrate the content of the former into
the latter.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It is unnecessary to split C library preparation into two steps, as only
one really makes sense. So, do_libc_headers is bound to be withdrawn
short-term, in favor of do_libc_start_files.
uClibc already had all its start files installation in do_libc_headers, and
do_libc_start_files was empty, just migrate the content of the former into
the latter.
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>
ia64 is broken in every gcc/glibc combinations I tested (except for the
existing sample that used very old versions).
Nobody complained on the list about not being able to build recent versions.
So the only way forward I can see is to remove the architecture altogether.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The location of the longterm Linux kernels on FTP has changed.
Here is a simple (but not very versatile) fix.
Signed-off-by: "Björn A. Herwig" <herwig@gdsys.de>
[yann.morin.1998@anciens.enib.fr: make it generic/versatile]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Latest version of CLooG does not have properly generated autoconf files,
so they need to be regenerated before the call to ./configure
Signed-off-by: "Ilya A. Volynets-Evenbakh" <ilya@total-knowlege.com>
[yann.morin.1998@anciens.enib.fr: make it conditional on 0.15.10 only]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
ltrace 0.5.3 currently fails to build for target mips because MY_TARGET
(introduced by patches/ltrace/0.5.3/150-allow-configurable-arch.patch)
is set to 'mips' via CT_ARCH, while the mips specific stuff in ltrace
(0.5.3) is stored under sysdeps/linux-gnu/mipsel:
result: *** No rule to make target `mips/arch.h', needed by `sysdep.h'.
Stop.
The following patch fixes this issue
Signed-off-by: "Horst Kronstorfer" <horst.kronstorfer@aon.at>
[yann.morin.1998@anciens.enib.fr: reformat commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To properly enable LTO with gold, gcc has to install a plugin that gold
uses to handle the LTO information.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When both gold and ld are installed, add a wrapper that calls
to either gold or ld.
In case the wrapper is installed, we also need to symlink ld.bfd
and ld.gold for the core_cc steps.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When configured with support for threads, gold can link in
parallel, possibly cooperating with a make jobserver.
Add an option enabling threads.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is a new, optimised, multi-threaded linker with support
for plugins.
Add support for gold starting with binutils 2.21. Although 2.20
also had gold, the configure flags have changed, and supporting
2.20 would be a mess in the code.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
libelf is used by gcc to build the lto-plugin used
by binutils' gold to perform LTO.
This requires that files in libelf be compiled with
-fPIC to generate a proper .so.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Hidden version names for uClibc conflicted:
LIBC_UCLIBC_V_0_9_30_2
LIBC_V_0_9_30_1
name them constantly as:
LIBC_UCLIBC_V_<version>
Also update the build script where we use snapshots by version or snapshots by date.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Like rev 2002, eglibc installs some bash scripts, but use the path to the
buildtool bash as the 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 shell on the target *will* be /bin/bash.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
headers_install makes .install and ..install.cmd files.
headers_check makes .check and ..check.cmd files.
Remove these files uncoditionaly after installing (and checking) header files
into the sys-root.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[Yann E. MORIN: reformat the patch, move hunk out of headers_check conditional]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It appears, that the configure scripts of libelf versions 0.8.13 and
0.8.12 do not honour the --host option. The compiler must be given as an
environment variable or the process will use the command "gcc" as the
compiler.
It seems that this is already done in the function do_libelf_target in
scripts/build/companion_libs/libelf.sh, but not in function do_libelf.
Do not try to strip any script.
Previously, only shell scripts were ignored, but when the Java frontend
is installed, it also installs a Python script. So we have to ignore
any "script text executable", and not restrict it to "shell script text
executable".
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Using a list of files to strip misses a few of them.
Now, scan appropriate directories, and strip all ELF
executables and shared objects.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
- add a new parameter to do_cc_core: build_statically=[yes|no]
- pass build_statically=yes in core_pass_2 when doing bare_metal
- fix handling the static / static libstdc++ / static complibs stuff
- add a commment to keep both blocks (in core and final) in sync
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the global static option is set, then build the final gcc statically.
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the global static option is set, then build binutils statically.
Signed-off-by: "Bryan Hundven" <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This rules out 0.15.5 and previous versions, that did not
have this option, so remove them from the list. Anyway,
they were marked 'OBSOLETE', so it's not a big loss...
[Yann E. MORIN: remove obsolete versions]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The version string was hard-coded.
Now, the version string follows the crosstool-NG version.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Since Subversion 1.6.13 was released, it is no longer possible
to checkout/export to the current working directory using '.'
(eg. "svn co bla://blabla/foo/bar ." no longer extracts the content
of bar into ./ but into ./bar).
Fix this by luring Subversion to extract into "$(pwd)", which has
the advantage of working both with all known versions so far.
At the same time, remove the useless redirection.
Adds support to enable/disable IOs of floating point values
(float, double, and long double).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This was intended as a fix for g++ not finding its headers,
but it breaks in othe horrible ways. So just revert it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
I ran into some minor difficulties looking through the build log for a
particular file: I wasn't interested in seeing it unpacked, but only
when it is built or installed. Adding these two levels allows me to
differentiate between those cases.
[Yann E. MORIN: Those are blind log levels, and are used only to search
in the build-log afterward.]
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
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>
libssp is the run-time Stack-Smashing Protection library.
It can be usefull to have or miss, depends...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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.
