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