summaryrefslogtreecommitdiff
path: root/docs/overview.txt
diff options
context:
space:
mode:
Diffstat (limited to 'docs/overview.txt')
-rw-r--r--docs/overview.txt29
1 files changed, 22 insertions, 7 deletions
diff --git a/docs/overview.txt b/docs/overview.txt
index 1176352..61b4cba 100644
--- a/docs/overview.txt
+++ b/docs/overview.txt
@@ -27,7 +27,9 @@ Running crosstool-NG
Note on // jobs
Tools wrapper
Using the toolchain
+ The 'populate' script
Toolchain types
+ Seemingly-native toolchains
Internals
Makefile front-end
Kconfig parser
@@ -154,11 +156,9 @@ Stay in the directory holding the sources, and run:
See below for complete usage.
-Now, provided you checked-out the code, you can send me your interesting changes
-by running:
- svn diff
-
-and mailing me the result! :-P
+Now, provided you used a clone of the repository, you can send me your changes.
+See the file README, at the top of crosstool-NG source, for how to submit
+changees.
Preparing for packaging |
------------------------+
@@ -398,7 +398,7 @@ toolchain.
The libraries are built as shared libraries, because building them as static
libraries has some short-comings. This poses no problem at build time, as
-crosstool-NG correctly points gcc (and binutiols and gdb) to the correct
+crosstool-NG correctly points gcc (and binutils and gdb) to the correct
place where our own version of the libraries are installed. But it poses
a problem when gcc et al. are run: the place where the libraries are is most
probably not known to the host dynamic linker. Still worse, if the host system
@@ -408,7 +408,7 @@ So we have to force the dynamic linker to load the correct version. We do this
by using the LD_LIBRARY_PATH variable, that informs the dynamic linker where
to look for shared libraries prior to searching its standard places. But we
can't impose that burden on all the system (because it'd be a nightmare to
-configure, and because two tolchains on the same system may use different
+configure, and because two toolchains on the same system may use different
versions of the libraries); so we have to do it on a per-toolchain basis.
So we rename all binaries of the toolchain (by adding a dot '.' as their first
@@ -590,6 +590,21 @@ anyway!)
were all being hashed out, Canada had three national political parties.
http://en.wikipedia.org/wiki/Cross_compiler
+Seemingly-native toolchains |
+----------------------------+
+
+Seemingly-native toolchains are toolchains that target the same architecture
+as the one it is built on, and on which it will run, but the machine tuple
+may be different (eg i686 vs. i386, or x86_64-unknown-linux-gnu vs.
+x86_64-pc-linux-gnu). This also applies if the target architecture is of the
+same kind (eg. x86 vs. x86_64, or ppc vs. ppc64).
+
+Such toolchain is tricky to build, as the configure scripts may incorrectly
+assume that files (headers and libs) from the build (or host) machine can be
+used by the cross-compiler it is going to build. The problem seems to arise
+only with glibc (and eglibc?) starting with version 2.7.
+
+
_____________
/
Internals /