Move documents to github.io

Will be pulled into release tarball by a release script.

Signed-off-by: Alexey Neyman <stilor@att.net>

1 files changed, 0 insertions, 403 deletions

diff --git a/docs/C - Misc. tutorials.txt b/docs/C - Misc. tutorials.txt
deleted file mode 100644
index 0735c9e..0000000
--- a/docs/C - Misc. tutorials.txt
+++ /dev/null
@@ -1,403 +0,0 @@
-File.........: C - Misc. tutorials.txt
-Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@free.fr>
-License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
-
-
-Misc. tutorials  /
-________________/
-
-
-Using crosstool-NG on FreeBSD (and other *BSD) |
------------------------------------------------+
-
-Contributed by: Titus von Boxberg
-
-Prerequisites and instructions for using ct-ng for building a cross toolchain on FreeBSD as host.
-
-0) Tested on FreeBSD 8.0
-
-1) Install (at least) the following ports
-   archivers/lzma
-   textproc/gsed
-   devel/gmake
-   devel/patch
-   shells/bash
-   devel/bison
-   lang/gawk
-   devel/automake110
-   ftp/wget
-
-   Of course, you should have /usr/local/bin in your PATH.
-
-2) run ct-ng's configure with the following tool configuration:
-   ./configure --with-sed=/usr/local/bin/gsed --with-make=/usr/local/bin/gmake \
-   --with-patch=/usr/local/bin/gpatch
-   [...other configure parameters as you like...]
-
-3) proceed as described in general documentation
-   but use gmake instead of make
-
-
-Using crosstool-NG on MacOS-X |
-------------------------------+
-
-Contributed by: Titus von Boxberg
-
-Prerequisites and instructions for using crosstool-NG for building a cross
-toolchain on MacOS as host.
-
-0) Mac OS Snow Leopard, with Developer Tools 3.2 installed, or
-   Mac OS Leopard, with Developer Tools & newer gcc (>= 4.3) installed
-   via macports
-
-1) You have to use a case sensitive file system for ct-ng's build and target
-   directories. Use a disk or disk image with a case sensitive fs that you
-   mount somewhere.
-
-2) Install macports (or similar easy means of installing 3rd party software),
-   make sure that macport's bin dir is in the front (!) of your PATH.
-   Furtheron assuming it is /opt/local/bin.
-
-3) Install (at least) the following macports
-   lzmautils
-   libtool
-   binutils
-   gsed
-   gawk
-   gcc43 (only necessary for Leopard OSX 10.5)
-   gcc_select (only necessary for OSX 10.5, or Xcode > 4)
-
-4) Prerequisites
-   On Leopard, make sure that the macport's gcc is called with the default
-   commands (gcc, g++,...), via macport's gcc_select
-
-   On OSX 10.7 Lion / when using Xcode >= 4 make sure that the default commands
-   (gcc, g++, etc.) point to gcc-4.2, NOT llvm-gcc-4.2
-   by using macport's gcc_select feature. With MacPorts >= 1.9.2
-   the command is: "sudo port select --set gcc gcc42"
-   This also requires (like written above) that macport's bin dir
-   comes before standard directories in your PATH environment variable
-   because the gcc symlink is installed in /opt/local/bin and the default /usr/bin/gcc
-   is not removed by the gcc select command!
-   Explanation: llvm-gcc-4.2 (with Xcode 4.1 it is on my machine
-   "gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)")
-   cannot boostrap gcc. See http://llvm.org/bugs/show_bug.cgi?id=9571
-
-5) run ct-ng's configure with the following tool configuration
-   (assuming you have installed the tools via macports in /opt/local):
-   ./configure --with-sed=/opt/local/bin/gsed                 \
-               --with-libtool=/opt/local/bin/glibtool         \
-               --with-libtoolize=/opt/local/bin/glibtoolize   \
-               --with-objcopy=/opt/local/bin/gobjcopy         \
-               --with-objdump=/opt/local/bin/gobjdump         \
-               --with-readelf=/opt/local/bin/greadelf         \
-               --with-grep=/opt/local/bin/ggrep               \
-               [...other configure parameters as you like...]
-
-6) proceed as described in standard documentation
-
------
-
-HINTS:
-- Apparently, GNU make's builtin variable .LIBPATTERNS is misconfigured
-  under MacOS: It does not include lib%.dylib.
-  This affects build of (at least) gdb-7.1
-  Put 'lib%.a lib%.so lib%.dylib' as .LIBPATTERNS into your environment
-  before executing ct-ng build.
-  See http://www.gnu.org/software/make/manual/html_node/Libraries_002fSearch.html
-  as an explanation.
-- ct-ng menuconfig will not work on Snow Leopard 10.6.3 since libncurses
-  is broken with this release. MacOS <= 10.6.2 and >= 10.6.4 are ok.
-
-
-Using Mercurial to hack crosstool-NG |
--------------------------------------+
-
-NOTE: this section was applicable as long as when we were using Mercurial (Hg)
-as the DVCS. Now we've switched to git, this section is no longer current. We
-keep it as a reference, since it still contains a few useful hints.
-
-Please help rewrite this section. ;-)
-
-Contributed by: Titus von Boxberg
-
-PREREQUISITES:
-
-Configuring Mercurial:
-  You need mercurial with the following extensions:
-   - mq        : http://mercurial.selenic.com/wiki/MqExtension
-   - patchbomb : http://mercurial.selenic.com/wiki/PatchbombExtension
-  Usually, these two extensions are already part of the installation package.
-  The mq extension maintains a separate queue of your local changes
-  that you can change at any later time.
-  With the patchbomb extension you can email those patches directly
-  from your local repo.
-
-  Your configuration file for mercurial, e.g. ~/.hgrc should contain
-  at least the following sections (but have a look at `man hgrc`):
-  # ---
-  [email]
-  # configure sending patches directly via Mercurial
-  from = "Your Name" <your@email.address>
-  # How to send email:
-  method = smtp
-
-  [smtp]
-  # SMTP configuration (only for method=smtp)
-  host = localhost
-  tls = true
-  username =
-  password =
-
-  [extensions]
-  # The following lines enable the two extensions:
-  hgext.mq =
-  hgext.patchbomb =
-  # ----
-
-Create your local repository as a clone:
-  hg clone http://crosstool-ng.org/hg/crosstool-ng crosstool-ng
-
-Setting up the mq extension in your local copy:
-  cd crosstool-ng
-  hg qinit
-
-
-CREATING PATCHES:
-
-Recording your changes in the patch queue maintained by mq:
-  # First, create a new patch entry in the patch queue:
-  hg qnew -D -U -e short_patch_name1
-  <edit patch description as commit message (see below for an example)>
-
-  <now edit the ct-ng sources and check them>
-
-  # if you execute `hg status` here, your modifications of the working
-  # copy should show up.
-
-  # Now the following command takes your modifications from the working copy
-  # into the patch entry
-  hg qrefresh -D [-e]
-  <reedit patch description [-e] if desired>
-
-  # Now your changes are recorded, and `hg status` should show a clean
-  # working copy
-
-Repeat the above steps for all your modifications.
-The command `hg qseries` informs you about the content of your patch queue.
-
-
-CONTRIBUTING YOUR PATCHES:
-
-Once you are satisfied with your patch series, you can (you should!)
-contribute them back to upstream.
-This is easily done using the `hg email` command.
-
-`hg email` sends your new changesets to a specified list of recipients,
-each patch in its own email, all ordered in the way you entered them (oldest
-first). The command line flag --outgoing selects all changesets that are in
-your local but not yet in the upstream repository. Here, these are exactly
-the ones you entered into your local patch queue in the section above, so
---outgoing is what you want.
-
-Each email gets the subject set to:  "[PATCH x of n] <series summary>"
-where 'x' is the serial number in the email series, and 'n' is the total number
-of patches in the series. The body of the email is the complete patch, plus
-a handful of metadata, that helps properly apply the patch, keeping the log
-message, attribution and date, tracking file changes (move, delete, modes...)
-
-`hg email` also threads all outgoing patch emails below an introductory
-message. You should use the introductory message (command line flag --intro)
-to describe the scope and motivation for the whole patch series. The subject
-for the introductory message gets set to:  "[PATCH 0 of n] <series summary>"
-and you get the chance to set the <series summary>.
-
-Here is a sample `hg email` complete command line:
-Note: replace " (at) " with "@"
-
-  hg email --outgoing --intro   \
-           --to '"Yann E. MORIN" <yann.morin.1998 (at) free.fr>'    \
-           --cc 'crossgcc (at) sourceware.org'
-
-  # It then opens an editor and lets you enter the subject
-  # and the body for the introductory message.
-
-Use `hg email` with the additional command line switch -n to
-first have a look at the email(s) without actually sending them.
-
-
-MAINTAINING YOUR PATCHES:
-
-When the patches are refined by discussing them on the mailing list,
-you may want to finalize and resend them.
-
-The mq extension has the idiosyncrasy of imposing a stack onto the queue:
-You can always reedit/refresh only the patch on top of stack.
-The queue consists of applied and unapplied patches
-(if you reached here via the above steps, all of your patches are applied),
-where the 'stack' consists of the applied patches, and 'top of stack'
-is the latest applied patch.
-
-The following output of `hg qseries` is now used as an example:
-  0 A short_patch_name1
-  1 A short_patch_name2
-  2 A short_patch_name3
-  3 A short_patch_name4
-
-You are now able to edit patch 'short_patch_name4' (which is top of stack):
-  <Edit the sources>
-  # and execute again
-  hg qrefresh -D [-e]
-  <and optionally [-e] reedit the commit message>
-
-If you want to edit e.g. patch short_patch_name2, you have to modify
-mq's stack so this patch gets top of stack.
-For this purpose see `hg help qgoto`, `hg help qpop`, and `hg help qpush`.
-
-  hg qgoto short_patch_name2
-  # The patch queue should now look like
-  hg qseries
-    0 A short_patch_name1
-    1 A short_patch_name2
-    2 U short_patch_name3
-    3 U short_patch_name4
-  # so patch # 1 (short_patch_name2) is top of stack.
-  <now reedit the sources for short_patch_name2>
-  # and execute again
-  hg qrefresh -D [-e]
-  <and optionally [-e] reedit the commit message>
-  # the following command reapplies the now unapplied two patches:
-  hg qpush -a
-  # you can also use `hg qgoto short_patch_name4` to get there again.
-
-
-RESENDING YOUR REEDITED PATCHES:
-
-By mailing list policy, please resend your complete patch series.
---> Go back to section "CONTRIBUTING YOUR PATCHES" and resubmit the full set.
-
-
-SYNCING WITH UPSTREAM AGAIN:
-
-You can sync your repo with upstream at any time by executing
-  # first unapply all your patches:
-  hg qpop -a
-  # next fetch new changesets from upstream
-  hg pull
-  # then update your working copy
-  hg up
-  # optionally remove already upstream integrated patches (see below)
-  hg qdelete <short_name_of_already_applied_patch>
-  # and reapply your patches if any non upstream-integrated left (but see below)
-  hg qpush -a
-
-Eventually, your patches get included into the upstream repository
-which you initially cloned.
-In this case, before executing the hg qpush -a from above
-you should manually "hg qdelete" the patches that are already integrated upstream.
-
-
-HOW TO FORMAT COMMIT MESSAGES (aka patch descriptions):
-
-Commit messages should look like (without leading pipes):
- |component: short, one-line description
- |
- |optional longer description
- |on multiple lines if needed
- |
- |Signed-off-by: as documented in section 7 of ct-ng's documentation
-
-Here is an example commit message (see revision 8bb5151c5b01):
- kernel/linux: fix type in version strings
-
- I missed refreshing the patch before pushing. :-(
-
- Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
-
-Using crosstool-NG on Windows |
-------------------------------+
-
-Contributed by: Ray Donnelly
-
-Prerequisites and instructions for using crosstool-NG for building a cross
-toolchain on Windows (Cygwin) as build and, optionally Windows (hereafter)
-MinGW-w64 as host.
-
-0. Use Cygwin64 if you can. DLL base-address problems are lessened that
-   way and if you bought a 64-bit CPU, you may as well use it.
-
-1. You must enable Case Sensitivity in the Windows Kernel (this is only really
-   necessary for Linux targets, but at present, crosstool-ng refuses to operate
-   on case insensitive filesystems). The registry key for this is:
-   HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive
-   Read more at:
-   https://cygwin.com/cygwin-ug-net/using-specialnames.html
-
-2. Using setup{,-x86_64}.exe, install the default packages and also the
-   following ones: (tested versions in brackets, please test newer versions
-   and report successes via pull requests changing this list and failures to:
-   https://github.com/crosstool-ng/crosstool-ng/issues
-   autoconf (13-1), make (4.1-1), gcc-g++ (4.9.3-1), gperf (3.0.4-2),
-   bison (3.0.4-1), flex (2.5.39-1), texinfo (6.0-1), wget (1.16.3-1),
-   patch (2.7.4-1), libtool (2.4.6-2), automake (9-1), diffutils (3.3-3),
-   libncurses-devel (6.0-1.20151017), help2man (1.44.1-1)
-   mingw64-i686-gcc-g++* (4.9.2-2), mingw64-x86_64-gcc-g++* (4.9.2-2)
-   Leave "Select required packages (RECOMMENDED)" ticked.
-   Notes:
-   2.1 The packages marked with * are only needed if your host is MinGW-w64.
-   2.2 Unfortunately, wget pulls in an awful lot of dependencies, including
-       Python 2.7, Ruby, glib and Tcl.
-
-3. Although nativestrict symlinks seem like the best idea, extracting glibc fails
-   when they are enabled, so just don't set anything here. If your host is MinGW-w64
-   then these 'Cygwin-special' symlinks won't work, but you can dereference them by
-   using tar options --dereference and --hard-dereference when making a final tarball.
-   I plan to investigate and fix or at least work around the extraction problem.
-   Read more at:
-   https://cygwin.com/cygwin-ug-net/using-cygwinenv.html
-
-4. collect2.exe will attempt to run ld which is a shell script that runs either
-   ld.exe or gold.exe so you need to make sure that a working shell is in your path.
-   Eventually I will replace this with a native program for MinGW-w64 host.
-
-Using crosstool-NG to build Xtensa toolchains |
-----------------------------------------------+
-
-Contributed by: Max Filippov
-
-Xtensa cores are highly configurable: endianness, instruction set, register set
-of a core is chosen at processor configuration time. New registers and
-instructions may be added by designers, making each core configuration unique.
-Toolchain components cannot know about features of each individual core and
-need to be configured in order to be compatible with particular architecture
-variant. This configuration includes:
-- definitions of instruction formats, names and properties for assembler,
-  disassembler and debugger;
-- definitions of register names and properties for assembler, disassembler and
-  debugger;
-- selection of predefined features, such as endianness, presence of certain
-  processor options or instructions for compiler, debugger C library and OS
-  kernels;
-- macros with instruction sequences for saving and restoring special, user or
-  coprocessor registers for OS kernels.
-
-This configuration is provided in form of source files, that must replace
-corresponding files in binutils, gcc, gdb or newlib source trees or be added
-to OS kernel source tree. This set of files is usually distributed as archive
-known as Xtensa configuration overlay.
-
-Tensilica provides such an overlay as part of the processor download, however,
-it needs to be reformatted to match the specific format required by the
-crosstool-NG. For a script to convert the overlay file, and additional
-information, please see
-  http://wiki.linux-xtensa.org/index.php/Toolchain_Overlay_File
-
-The current version of crosstool-NG requires that the overlay file name has the
-format xtensa_<CORE_NAME>.tar, where CORE_NAME can be any user selected name.
-To make crosstool-NG use overlay file located at <PATH>/xtensa_<CORE_NAME>.tar
-select XTENSA_CUSTOM, set config parameter CT_ARCH_XTENSA_CUSTOM_NAME to
-CORE_NAME and CT_ARCH_XTENSA_CUSTOM_OVERLAY_LOCATION to PATH.
-
-The fsf target architecture variant is the configuration provided by toolchain
-components by default. It is present only for build-testing toolchain
-components and is in no way special or universal.