docs/7 - Contributing to crosstool-NG.txt
author Daniel Price <daniel.price@gmail.com>
Tue Nov 20 16:59:17 2012 -0800 (2012-11-20)
changeset 3126 333d3e40cbd1
parent 2700 e8d25b041de5
permissions -rw-r--r--
scripts: refine static linking check to better guide the user

The current mechanism to check if static linking is possible, and the mesage
displayed on failure, can be puzzling to the unsuspecting user.

Also, the current implementation is not using the existing infrastructure,
and is thus difficult to enhance with new tests.

So, switch to using the standard CT_DoExecLog infra, and use four tests to
check for the host compiler:
- check we can run it
- check it can build a trivial program
- check it can statically link that program
- check if it statically link with libstdc++

That should cover most of the problems. Hopefully.

(At the same time, fix a typo in a comment)

Signed-off-by: Daniel Price <daniel.price@gmail.com>
[yann.morin.1998@free.fr: split original patch for self-contained changes]
[yann.morin.1998@free.fr: use steps to better see gcc's output]
[yann.morin.1998@free.fr: commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <163f86b5216fc08c672a.1353459722@nipigon.dssd.com>
Patchwork-Id: 200536
     1 File.........: 7 - Contributing to crosstool-NG.txt
     2 Copyright....: (C) 2010 Yann E. MORIN <yann.morin.1998@free.fr>
     3 License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
     4 
     5 
     6 Contributing to crosstool-NG  /
     7 _____________________________/
     8 
     9 
    10 Sending a bug report |
    11 ---------------------+
    12 
    13 If you need to send a bug report, please send a mail with subject
    14 prefixed with "[CT_NG]" with to following destinations:
    15     TO: yann.morin.1998 (at) free.fr
    16     CC: crossgcc (at) sourceware.org
    17 
    18 
    19 Sending patches |
    20 ----------------+
    21 
    22 If you want to enhance crosstool-NG, there's a to-do list in the TODO file.
    23 
    24 When updating a package, please include the category and component in the
    25 start of the description. For example:
    26     cc/gcc: update to the Linaro 2011.09 release
    27 
    28 Here is the (mostly-complete) list of categories and components:
    29 
    30     Categories  | Components
    31     ------------+-------------------------------------------------------
    32     arch        | alpha, arm, mips, powerpc...
    33     cc          | gcc
    34     binutils    | binutils, elf2flt, sstrip
    35     libc        | eglibc, uClibc, glibc, newlib, mingw, none
    36     kernel      | linux, mingw32, bare-metal
    37     debug       | dmalloc, duma, gdb, ltrace, strace
    38     complibs    | gmp, mpfr, ppl, cloog, mpc, libelf
    39     comptools   | make, m4, autoconf, automake, libtool
    40     ------------+-------------------------------------------------------
    41                 | The following categories have no component-part:
    42     samples     | when adding/updating/removing a sample
    43     kconfig     | for stuff in the kconfig/ dir
    44     docs        | for changes to the documentation
    45     configure   | for changes to ./configure and/or Makefile.in
    46     config      | for stuff in config/ not covered above
    47     scripts     | for stuff in scripts/ not covered above
    48 
    49 
    50 Patches should come with the appropriate SoB line. A SoB line is typically
    51 something like:
    52    Signed-off-by: John DOE <john.doe@somewhere.net>
    53 
    54 The SoB line is clearly described in Documentation/SubmittingPatches , section
    55 12, of your favourite Linux kernel source tree.
    56 
    57 Add the following to your ~/.hgrc to make Mercurial check for the SoB
    58 line when committing:
    59     [hooks]
    60     pretxncommit.signoff = hg log --template '{desc}\n' -r $HG_NODE \
    61         | grep -qi '^signed-off-by:'
    62 
    63 You can also add any of the following lines if applicable:
    64     Acked-by:
    65     Tested-by:
    66     Reviewed-by:
    67 
    68 For larger or more frequent contributions, mercurial should be used.
    69 There is a nice, complete and step-by-step tutorial in section 'C'.