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>
Update all samples to reflect the new set of options, plus:
- remove the arm-iphone-linux-gnueabi sample (obsolete...)
- disable hard-float in ARM bare-metal samples.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
#0a0410dd0cb0 broke #0cc4d6352c3e. This patch fixes this, which fixes the build
of gcc/glibc/gdb manuals.
Signed-off-by: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
Now that ./configure is generated by autoconf, it must be generated
before the release tarball is made. So, we can not simply use hg's
archive, we must post-process it.
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>
In the process of converting to autoconf, the kconfig option
were not properly translated.
Fix that.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
We need just 'grep', and we need to be able to call it with 'grep -E'.
Check for 'grep', and bailout if egrep != grep -E
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The tools found by the new autostuff configure can contain arguments,
for example: grep -E
This needs separating the paths set for the Makfile from the paths
set for the scripts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The real sources for a few files are the lex/yacc/gperf
files, and the C files are only generated...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The kconfig frontends are currently instaleld as source files. This is
a remnant of the early times, when I wanted a single installation of
crosstool-NG to be shared across multiple machines, potentially of
different architectures.
This does not really make sense, and it's been a long time since it
was las tpossible in practice.
So, just build the kconfig frontends at make-time, and install them
as we do for all other crosstool-NG dependent files.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Create configure.ac, an autoconf script to generate ./configure
This will be needed by a subsequent patch to properly handle
--build and --host, and more tests, when the kconfig stuff will
be installed pre-built.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
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>
Konrad submitted an initial patch adding multlib support:
http://sourceware.org/ml/crossgcc/2011-11/msg00040.html
The patch was full of good ideas, but had a few issues, so
I (Yann E. MORIN) started it all from scatch, re-using part
of the original patch. This got implemented in this series:
hg log -r 446a17b5dd1e:e47d17391ae3
As I forgot to credit Konrad in these changelogs, update the
docs so that the work by Konrad gets credited. Without his
initial effort, we would probably not have had multlib support
so soon. Thank you Konrad!
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>
