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         \

               [...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 |

-------------------------------------+

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>